On Thu, 7 Dec 2006, seth vidal wrote:
On Tue, 2006-12-05 at 13:21 +0000, Matej Cepl wrote:
seth vidal scripst:
I don't think anyone is opposed to the idea of suggests/recommends
inherently. I, for one, would just like us to make sure we understand
the policies that it entails. Especially when we think of things like
'enhances' which is a reverse dependency.
I am not sure I understand your question -- is this the answer
http://www.us.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps ?
Not exactly. Though I did learn something fun this week. Apt in debian
doesn't do anything about 'enhances' or 'recommends' other than print
them to stdout.
Actually apt in Debian (or elsewhere) doesn't even *know* about
'enhances'. It only prints info about suggests and recommends...
https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-January/000672.html
In fact, neither aptitude or synaptic knows about enhances either. Looking
at dpkg source, it doesn't know much about enhances either, only that such
a tag exists and is shown if you view package dependency information
(think of rpm --requires/--provides kind of info). Given how much hoopla
we've seen about dpkg being superior to rpm because it supports enhances
and suggests and all ... yawn.
That'd be pretty easy to facilitate ;)
Indeed, not much policy involved ;)
Now, I do think soft dependencies *would* be a powerful feature, correctly
and sparingly used and actually implemented in the tools. How I personally
think it should be done, is two levels of soft dependencies (btw this is
how Suse's rpm fork implements it, JBJ's rpm only has one level): there
are strong and weak dependency hints.
A strong dependency hint could be for example Evolution requiring
spamassassin, which it doesn't need to run, but is handy if you don't have
spam checked for incoming mails by other means. Strong dependency hint
would be something that you'd probably want to install by default
automatically in 'yum install foo' situation. It's also something you can
just rpm -e / yum remove later, and in that case it wont be pulled back in
on upgrade. You don't really need an extra database for that either, it's
possible to calculate it from existing data (installed package A has
dependency hint on B but B is not installed, so the user doesn't want it
etc)
A weak dependency hint is something you probably never want to install
automatically, it's more just extra information that interactive tools can
prompt for or just show "you might find these packages useful with this
software".
So you have something like (IIRC this is how Suse rpm does it but mind you
it's been a while since I looked at the source):
Requires: foo # a hard dep as we know it
Requires(hint): bar # a strong dependency hint
Requires(weak): bar-foo # a weak dependency hint
- Hard dependency is something the package wont run without.
- Strong hint is something you want generally to be installed by default, but
removing wont stop the package from running and dependencies wont be
broken.
- Weak hint is just "you might also be interested in these packages" info
when viewing such info is feasible.
Enhances is also two-level thing, and much like requires hints, but with
some twists because it gives control of dependencies to "3rd party
packages", so you need to be extra careful with them.
Strong enhances hint is something you'd almost never want to use "in the
wild", assuming similar semantics as for requires where strong hints are
automatically installed. BUT it would be extremely handy in certain
specific cases. For example, at work we have a firefox-corp package which
contains configuration, bookmarks etc for firefox, which we'd like to have
pulled in any time firefox is installed. Currently there's no way to do
that.
Weak enhances hint (which is what Debian's enhances is) is again just info
that tools *can* use if they so wish (prompt for, just show the info or
so). Useful with 3rd party plugins / other addons to software where the
main software package is not aware of these enhancements.
Allowing soft dependencies to be present doesn't mean they should be used
on every other package, nor does it necessarily mean that much in the
tools above rpm (and rpm-level implementations already exist) - all apt
does is a printf() on Suggests/Recommends, aptitude and synaptic actually
prompt and allow individual packages to be selected from the list. Like
Seth said, a print in yum doesn't cost much ;)
Soft dependencies are no silver bullet, they certainly add some extra
complexity if fully implemented in tools, and they should be used with
care. But they DO offer some nice possibilities which are currently
impossible.
P.S. Actually comps.xml as used by anaconda is already a kind of soft
dependency provider, I've seen comments like "well it's installed by
default from comps so foo doesn't need to require it" over the years.
Pffft. Maybe, hopefully, come the next 6 month cycle to talk about soft
dependencies I'm able to shut up.
- Panu -
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
