I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what Requires(hint) might do, but Requires(missingok) sounds more like it wouldn't actually do anything if the dependency is not present, which would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
- J<
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what Requires(hint) might do, but Requires(missingok) sounds more like it wouldn't actually do anything if the dependency is not present, which would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
no - at least for yum it is not supported.
-sv
seth vidal wrote:
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what Requires(hint) might do, but Requires(missingok) sounds more like it wouldn't actually do anything if the dependency is not present, which would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
no - at least for yum it is not supported.
Is there any way of softdependencies supported by yum? Is this planned for the the future, for plugin basd apps it would be nice to be able to hint to the end user that certain optional plugins (with perhaps some hefty deps) would be good to install, then in beginning user mode (== default) yum could treat these as harddeps, and more advanced users could reconfigure the behavior to for example ask the user, or just not install soft-deps.
Regards,
Hans
On Mon, Mar 03, 2008 at 09:28:41AM +0100, Hans de Goede wrote:
seth vidal wrote:
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what Requires(hint) might do, but Requires(missingok) sounds more like it wouldn't actually do anything if the dependency is not present, which would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
no - at least for yum it is not supported.
Is there any way of softdependencies supported by yum? Is this planned for the the future, for plugin basd apps it would be nice to be able to hint to the end user that certain optional plugins (with perhaps some hefty deps) would be good to install, then in beginning user mode (== default) yum could treat these as harddeps, and more advanced users could reconfigure the behavior to for example ask the user, or just not install soft-deps.
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Rich.
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
Is there any way of softdependencies supported by yum? Is this planned for the the future, for plugin basd apps it would be nice to be able to hint to the end user that certain optional plugins (with perhaps some hefty deps) would be good to install, then in beginning user mode (== default) yum could treat these as harddeps, and more advanced users could reconfigure the behavior to for example ask the user, or just not install soft-deps.
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last time I checked, apt just lists out suggests/recommends to the terminal w/o doing anything with them.
Seriously - these are the hard questions to answer: 1. if foo suggests bar, baz and quux and the user is using -y in yum or using kickstart to install do we: a. automatically install them b. automatically ignore them c. something in between?
2. If foo suggest bar, baz, quux and the user has asked to remove foo do we: a. automatically remove them b. automatically ignore them c. something in between?
If we do A in both cases then they're just dependencies and should be left that way.
If we do B then they're nothing to the user and don't matter
Now, the first question is: "But what about interactive modes, couldn't you prompt and ask the user what to do?" The problem is installing rpms is a non-interactive business and we have to have a sensible answer for the non-interactive modes before anything else. Moreover, if we have a sensible answer for non-interactive why would we bug the user to ask them what to do along the way if our answer is sensible?
-sv
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last time I checked, apt just lists out suggests/recommends to the terminal w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on Debian I'll see a suggestion that looks worthwhile, kill the apt-get, and start it again with the extra package. Of course what Debian is then missing is an explanation of what the extra package does and why it enhances the requested package, eg:
yum install foo
foo suggests bar bar: with this package you will be able to foo bars as well
Rich.
On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last time I checked, apt just lists out suggests/recommends to the terminal w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on Debian I'll see a suggestion that looks worthwhile, kill the apt-get, and start it again with the extra package. Of course what Debian is then missing is an explanation of what the extra package does and why it enhances the requested package, eg:
yum install foo
foo suggests bar bar: with this package you will be able to foo bars as well
so the above does nothing for the most useful case of anaconda, then.
-sv
On Mon, 2008-03-03 at 10:08 -0500, seth vidal wrote:
On Mon, 2008-03-03 at 15:04 +0000, Richard W.M. Jones wrote:
On Mon, Mar 03, 2008 at 09:26:10AM -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:57 +0000, Richard W.M. Jones wrote:
Worth comparing what Debian do:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
you'll note debian doesn't specify behavior. So much in fact b/c, last time I checked, apt just lists out suggests/recommends to the terminal w/o doing anything with them.
Even just listing them out is (IMHO) a good thing. Sometimes on Debian I'll see a suggestion that looks worthwhile, kill the apt-get, and start it again with the extra package. Of course what Debian is then missing is an explanation of what the extra package does and why it enhances the requested package, eg:
yum install foo
foo suggests bar bar: with this package you will be able to foo bars as well
so the above does nothing for the most useful case of anaconda, then.
I think Anaconda will have to treat soft deps as hard deps.
~spot
"TC" == Tom "spot" Callaway <Tom> writes:
TC> I think Anaconda will have to treat soft deps as hard deps.
Or it (and yum) could ignore them completely and push the entire off to some additional application which gives you the current set of suggestions for what you have installed.
- J<
On Mon, 2008-03-03 at 09:28 +0100, Hans de Goede wrote:
Is there any way of softdependencies supported by yum? Is this planned for the the future, for plugin basd apps it would be nice to be able to hint to the end user that certain optional plugins (with perhaps some hefty deps) would be good to install, then in beginning user mode (== default) yum could treat these as harddeps, and more advanced users could reconfigure the behavior to for example ask the user, or just not install soft-deps.
Since rpm doesn't support it, it doesn't really matter.
-sv
On Mon 03-Mar-2008 at 09:28 +0100, Hans de Goede wrote:
Is there any way of softdependencies supported by yum? Is this planned for the the future, for plugin basd apps it would be nice to be able to hint to the end user that certain optional plugins (with perhaps some hefty deps) would be good to install
Surely this information already exists in the database?
A gimp plugin already has a 'Requires: gimp', so it ought to be possible to select the gimp in some (imaginary) GUI and be offered add-on packages that would be useful with the gimp.
`repoquery --whatrequires gimp` really does return a good list of add-ons, and the advantage is that the gimp packager doesn't need to list all possible past and future plugins.
On Sun, 2008-03-02 at 16:35 -0600, Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
What is this actually supposed to do? I can understand what Requires(hint) might do, but Requires(missingok) sounds more like it wouldn't actually do anything if the dependency is not present, which would make me wonder as to the point of having it at all.
Do we want Requires(missingok) in Fedora packages?
no - at least for yum it is not supported.
Rpm doesn't support that either as of 4.4.2.x, but the parsing of Requires(foo) attributes is somewhat broken so it doesn't report the error as such in all cases (yes, it's a bug of course).
Requires(missingok) means just as much to rpm 4.4.2.x as Requires(arbitraryjunk)
- Panu -
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of PM> Requires(foo) attributes is somewhat broken so it doesn't report PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post), Requires(pre) and such mean. So going by that, Requires(hint) or Requires(missingok) would indicate a dependency for the %hint or %missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the imagination, but I can't see the motivation for taking something which actually made sense and shovelling in a load of turds for no reason.
- J<
On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of PM> Requires(foo) attributes is somewhat broken so it doesn't report PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post), Requires(pre) and such mean. So going by that, Requires(hint) or Requires(missingok) would indicate a dependency for the %hint or %missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the imagination, but I can't see the motivation for taking something which actually made sense and shovelling in a load of turds for no reason.
+!
-sv
On Mon, 2008-03-03 at 11:16 -0500, seth vidal wrote:
On Mon, 2008-03-03 at 10:13 -0600, Jason L Tibbitts III wrote:
> "PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> Rpm doesn't support that either as of 4.4.2.x, but the parsing of PM> Requires(foo) attributes is somewhat broken so it doesn't report PM> the error as such in all cases (yes, it's a bug of course).
What really bothers me is that we already know what Requires(post), Requires(pre) and such mean. So going by that, Requires(hint) or Requires(missingok) would indicate a dependency for the %hint or %missingok scriptlets. Which, uh, they don't.
I know that rpm specfile syntax isn't clean by any stretch of the imagination, but I can't see the motivation for taking something which actually made sense and shovelling in a load of turds for no reason.
+!
or +1, even. you know, without the sticky shift key :/
-sv
Jason L Tibbitts III wrote:
I saw a review ticket for a package which uses Requires(missingok): which I have not seen before. Some searching turned up the kismet and python-docutils which currently use this idiom.
Just a note: I've removed the missingok from python-docutils in rawhide as it seems to be plainly wrong.
-Toshio
packaging@lists.fedoraproject.org
-
Bruno Postle -
Hans de Goede -
Jason L Tibbitts III -
Panu Matilainen -
Richard W.M. Jones -
Seth Vidal -
Tom Callaway -
Toshio Kuratomi