Red Hat Bugzilla – Bug 152450
yum still lacks an aggressive policy
Last modified: 2014-01-21 17:51:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.54 [en]
Description of problem:
Consider: yum -y install --enablerepo=extras '*', which ends with
Error: php-eaccelerator conflicts with php-mmcache
Error: wxGTK2-devel conflicts with wxGTK-devel
Error: Missing Dependency: libgwenhywfar.so.17 is needed by package aqhbci-qt-
Error: wxGTK-devel conflicts with wxGTK2-devel
Error: Missing Dependency: kernel-module-thinkpad >= 0:3.2 is needed by package
Error: Missing Dependency: libofx.so.1 is needed by package grisbi
Error: oidentd conflicts with pidentd
Error: proftpd conflicts with vsftpd
Error: gpgme03-devel conflicts with gpgme-devel
Error: Missing Dependency: libaqbankingpp.so.0 is needed by package aqhbci-qt-
Error: Missing Dependency: libaqbanking.so.0 is needed by package aqhbci-qt-
Error: gktools conflicts with gnome-kerberos
Error: sylpheed-claws conflicts with sylpheed
Error: Missing Dependency: libaqhbci.so.2 is needed by package aqhbci-qt-tools
Error: suck conflicts with leafnode
The purpose of the package manager, as I understand, is to preclude "dependency
hell", yes? Having an "excuse" about why yum failed to install anything is
pointless. yum should have some policy which resolves _whatever_ problems might
be encountered! So, for instance, "the package which is listed first,
alphabetically, gets installed, whenever there is a conflict", or "conflicting
packages are both installed, and a warning is printed".
Let people argue about the policy; policy can be changed. Differences of
opinion about policy preferences are much more useful than "dependency hell".
YUM STILL LACKS A "DO WHAT YOU CAN" OPTION. So yum _has_ a policy, it's just a
"when in doubt, do nothing" policy, which sucks.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.yum -y install --enablerepo=extras '*'
Actual Results: nothing useful
Expected Results: install something
we prefer to think of it as a "don't reduce my box to a ball of molten goo"
policy, but that may just be semantics
I think the reason for this policy is that the folks who originally developed
yum (me) and still develop yum are sysadmins, for the most part. We value
stability and consistency from the tools more than whizbang action. We also,
from our years of experience, have determined that while there are users who
want to do as much as possible and damn the consequences that most users like
for their systems to not explode.
as a general rule I'd say:
yum --enablerepo=extras install '*' is an extraordinarily bad idea.
I'm closing this wontfix, there may be ways around this problem in the future
but I doubt we'll ever enable a 'breakmysystem' option.
I don't find these arguments to be realistic, and certainly not persuasive.
They are generalities, not specific. One must imagine that these arguments rely
upon hidden components - superstition, or job security, or windows sysadmin
What do you expect to happen with "install '*'", really? What does "molten goo"
actually mean here? It sounds kewal, but hides a rather trivial result, I think.
Only where a package installation implies some kind of arogant "set as the
default file/application" could there be any actual conflict. Basically, a
package would have to overwrite a configuration file, or worse, write files with
filenames already being used by other packages. This would be fundamentally
broken behavior on its face, a fundamental problem with the package, not having
anything to do with the package manager. The only practical examples of this I
can think of are the proprietary Nvidia drivers that overwrite the gl libraries
with incompatible versions, which is to say, use the same filename for a
completely different kind of file, and certain RedHat libraries, that use the
same filename for different CPU specific files. But hey, this isn't MS windows
we are talking about, and arogantly overwriting other package's files are why
proprietary drivers are not allowed in general distribution.
Unless the intent is to allow or even promote this "won't play nicely with
others" package behavior - proprietary Fedora? - there is no excuse for
crippling the package manager.
BTW - doh! - simply using the "exclude" option in the yum configuration file can
go a long way to resolving any system-specific dependency concerns. So a simple
compromise feature for yum - though maybe not so simple to implement - would be
for yum to print a suggested set of "exclude" statements which would resolve the
dependency errors and allow installation to procede, possibly in the form
exclude <A> OR exclude <B>
This format would probably be easier for the user to understand, and would
continue to allow the sysadmin to decide what does and doesn't get installed.
What do you think?
1. you know --exclude is an option you can pass on the commandline, too.
2. it's not always obvious what's the best path to exclude.