On 30 July 2013 16:29, Tethys <tethys@xxxxxxxxx> wrote: > On Mon, Jul 29, 2013 at 3:30 AM, Marko Vojinovic <vvmarko@xxxxxxxxx> 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
