On Debian and Fedora experiences

[Panu Matilainen]

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 -