Bug 152450
Summary: | yum still lacks an aggressive policy | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | james |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | katzj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-30 05:39:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
james
2005-03-29 17:12:37 UTC
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 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. 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? 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. |