Do I need avahi?

Ian Malone ibmalone at gmail.com
Tue Jul 30 16:15:08 UTC 2013


On 30 July 2013 16:29, Tethys <tethys at gmail.com> wrote:
> On Mon, Jul 29, 2013 at 3:30 AM, Marko Vojinovic <vvmarko at gmail.com> wrote:
>
>> You suggest the scenario where just package A would be installed, and if
>> I happen to need some functionality of A (as opposed to some more
>> elementary functionality of A which would be good enough for you), I
>> would need to install B manually. But the features of B that are used
>> by A might also work in B only if some other package C is installed, so
>> I would need to install that manually as well. And so on...
>>
>> This chain of "optional" dependencies could continue indefinitely, and
>> is called "Dependency Hell". It's a very descriptive name, and soft
>> dependencies are not supported precisely to avoid those situations.
>
> Nope. Dependency hell is what we currently have and is IMHO the single
> biggest problem facing Fedora. I've filed countless bugs about excessive
> dependencies, and a few have been fixed. But there needs to be a systematic
> approach to this in the form of a policy saying "only provide the absolute
> minimum hard dependencies for a package". Of course, this would benefit
> hugely from soft dependencies in rpm, which others have claimed don't
> yet exist. I don't know why you think you'd need to install dependencies
> manually in such a scenario. Just add a flag to yum to say:
>
>         yum --optional-deps install foo
>

I'm not entirely clear from your email whether or not you understand
why most dependencies exist. If a linked library is not present the
program will not run, regardless of whether you need the functionality
provided by the library or not. If the programmer wishes to have the
option to use the functionality without requiring linking then they
must arrange to have it handled by a separate module which dynamically
loads the library (as opposed to dynamically links), or a less elegant
but sometimes workable alternative which is to split that
functionality into a spearate program which is run by the first one.
Being able to build modules separately is something that has to come
from upstream. See for instance the various gstreamer plugin packages.
For programs written in scripting languages the situation is a bit
more blurred as failure may only occur once the relevant codepath is
triggered. Here prior checking and enabling and disabling of available
functionality based on library availability is the equivalent of
module support. If upstream hasn't provided that for something you
don't think is 'core' to the application then the choice is between
having packages which simply crash in some instances or making it a
dependency.
An --optional-deps flag as you describe could only install *more*
libraries, not fewer, pulling in the required libraries for separately
packaged modules.

-- 
imalone
http://ibmalone.blogspot.co.uk


More information about the users mailing list