On 17/01/2008, Cameron Simpson wrote: > > I too am in dependency hell. I have multiple 3rd party repositories > active (why? not all have all packages). They conflict, as bemoaned > repeated on this list and elsewhere. That is a new and artificially created dependency hell and not the original one. Originally, RPM users had to resolve dependencies manually. With or without help of options like --aid, --whatprovides and additional scripts, and often they were ignorant to the fact that they had to use RPM properly i.e. install multiple packages at once to make it happy. Nowadays, software automation performs all those steps. But human beings work against the software and create data that breaks the software. And after years of Fedora packaging, there's still no sufficient, binding and common set of policies that avoids conflicts or dependency issues. It's not easy to solve. One cannot blame just the 3rd party packagers if Fedora packagers split/name their packages at their liking or even revert such changes at a later point when they're fed up with overcomplicated packaging. Too many or too unprecise Obsoletes/Provides tags bear a big risk of causing repo compatibility problems, too. It's not the first time a Fedora packager has made up a versioned SONAME for a library (sometimes after a package had passed the review) that is offered as only a static lib by the software developers and packaged as such in a 3rd party repo. Dependency issues with library packages are not limited to that, but they have burnt Fedora users several times when enabling additional repos. The burden of avoiding repository compatibility problems is on the 3rd party packagers' shoulders. Unless you manage to get Fedora packagers to monitor 3rd party repositories, some of which they may not even have heard of before. Else everything depends on whether, when and where a bug is reported before problems are fixed. > However, I now have a box where I can't upgrade some perl packages. > It seems one repository has split out a package from the core perl > package, and disaster follows. Removing perl to clean up will probably > try to remove half the system through dependency mania. Rumours have it that one of the main Fedora Perl packagers has left the project some months ago because of disagreement over how the core Perl package was changed. Now, I can't and don't want to be everywhere, but if the rumours are true (and possibly it's been a topic on a related ML), it adds to the fact that even within the Fedora Project there are conflicts and people who are not willing to agree to a compromise. > | Many--if not all--of his "issues" are > | self-inflicted. > > _All_ our issues are self inflicted. Splitting-hairs. There's a big difference between running Fedora as a normal user and (ab)using superuser privileges to damage it. > Yes, but one thing RPM seems to lack, and which is IMHO a great flaw, is > a distinction between package requirements and package recommendations. I'm not up-to-date on "Requires(hint): ..." and alikes. To my knowledge, they are not fully implemented yet and neither supported by the relevant package tools. http://fedoraproject.org/wiki/rpm-devel Apart from that, for a lot of software using optional dependencies is not feasible, because features are hardcoded (i.e. linked in at build-time) and cannot be added/removed at run-time or when starting the software. One can only hope that once the new "Requires" tags take off, the chains of optional dependencies stay simple and manageable for both the users and the package maintainers. Features like "yum groupinstall kde-desktop" are great. But the reverse command, "groupremove", is as dangerous as "remove" and takes away much more than just the kde-desktop.
