[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: That ole Livna Problem/That ole VLC Problem



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]