Aurelien Bompard wrote:
Jeff Spaleta wrote:
However, nautilus requires gnome-vfs2-smb though an explicit requires
on gnome-vfs2-smb, a decision made by the packager to ensure that the
runtime detectable smb support is always available when nautilus is
installed to provide a perfectly reasonable and recommended default
behavior for the average gnome desktop user. Some would argue doing
this is bending the purpose of 'requires' field out of necessity to
be used as a 'suggests' or 'recommends' field which rpm doesn't yet
have support for.
I have run into this kind of problem several times (and I've learned
packaging only two years ago). For example with showimg (an image viewer),
which can use kipi-plugins to add features, or with psi (a jabber client),
which can use qca-tls for SSL support.
The main objection I got from the RH folks when I proposed some kind of
"recommands" before, is that most of the time the dependancies are set at
compile-time, and thus are hardcoded.
But I think that more and more applications use a plugin system to add
features. Those plugins should remain plugins, and thus should not be set
as an hardcoded dependancy.
The proposal is for "missingok", not Recommends:, Enhances:, Suggests: or any other
goosey-loosey crapola with poorly defined DWIM that is impossible to implement, let
alone debug.
The specific difference is that dependencies marked with "missingok" are passed to
a depsolver, which is entirely at liberty to do whatever it wants with the information.
And the other difference is that rpmlib is responsibly only for passing the information
to the depsolver, and then ignoring the dependecy.
That definition is well defined mechanism, unlike Recommends: et al.
But of course, adding such a feature in RPM would need a very large amount of work to be supported properly from rpm to the user's wrappers. Nevertheless, I think "suggests" support could be added in RPM without breaking the wrappers, and complete support could be added later on. The wrapper which do not know of it yet would just ignore it. Would older implementation of RPM just ignore the tag when asked to rebuild a "suggests"-enabled spec file ? It's a lot of work, but I think it is worth it and it can be done one step at a time without breaking existing software.
Of course, that's just my 0.02 and I don't know the inner workings of RPM
very well.
I do know the innards of rpm upside down and inside out, and the "missingok" implementation is
3 hours work, with no obvious legacy problems.
That is not true for Recommends: et al.
73 de Jeff
