Bug 152450 - yum still lacks an aggressive policy
yum still lacks an aggressive policy
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-29 12:12 EST by james
Modified: 2014-01-21 17:51 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-30 00:39:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description james 2005-03-29 12:12:37 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-
tools
 Error: wxGTK-devel conflicts with wxGTK2-devel
 Error: Missing Dependency: kernel-module-thinkpad >= 0:3.2 is needed by package 
tpctl
 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- 
tools
 Error: Missing Dependency: libaqbanking.so.0 is needed by package aqhbci-qt-
tools
 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):
yum-2.2.1-0.fc3

How reproducible:
Always

Steps to Reproduce:
1.yum -y install --enablerepo=extras '*'
2.
3.
  

Actual Results:  nothing useful

Expected Results:  install something

Additional info:
Comment 1 Michael Stenner 2005-03-29 13:42:10 EST
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
Comment 2 Seth Vidal 2005-03-30 00:39:48 EST
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.
Comment 3 james 2005-03-30 14:40:40 EST
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
experience.

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.
Comment 4 james 2005-03-30 15:58:47 EST
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>
 exclude <C>

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?
Comment 5 Seth Vidal 2005-03-31 00:01:26 EST
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.


Note You need to log in before you can comment on or make changes to this bug.