On Mon, Jul 11, 2011 at 8:40 PM, James Antill <[email protected]> wrote: > On Mon, 2011-07-11 at 19:05 +0200, [email protected] wrote: > >> Do we really need all these cases ? >> I can see the use for -y for installing/updating stuff, but not >> removing stuff. but having options for all possible combination seams >> like overkill for me and it make the code very complex and hard to >> read. > > I've been thinking about this for a few days, and eventually just > decided to try something, as Seth wanted basically: > > allow me to do '''yum remove blah\*''', but only if there are no deps. > being removed too" > > ...which, in theory, just means removing the checked for "is removal" > maybe-and the checks for "txmbr.name in extcmds". The problem is that > doing this "minimal" change means that remove and install are toggled by > the same switch ... where seems unlikely to be desired by everyone, and > means there's no good way to be backwards compatible with current > behaviour. > > At the other end, I could see people wanting to distinguish between > deps. on upgrade vs. deps. on removals ... and even things like local > packages, or clean_requirements_on_remove deps. > > In the end I thought I'd go for listing the types of txmbr, the two old > tests and added in the three options for skip-broken and load-ts ... > then I could see what everyone thought? > So would you use it, if we just removed the "txmbr.ts_state == 'e'" > part of the conditional? Any other thoughts on how we could change it to > be useful? > > _______________________________________________ > Yum-devel mailing list > [email protected] > http://lists.baseurl.org/mailman/listinfo/yum-devel >
`install' - Prompt if something will be installed. This is ok `remove' - Prompt if something will be removed. This is ok `upgrade' - Prompt if something will be upgraded. This is ok `downgrade' - Prompt if something will be downgraded. Just a special kind of upgrade, where you upgrade a current package with a older version (could be handled by the upgrade flag) `reinstall' - Prompt if something will be reinstalled. Just a special kind of upgrade (could be handled by the upgrade flag) `obsoleter' - Prompt if something will obsolete other packages. Just a special kind of upgrade (could be handled by the upgrade flag) `obsoleted' - Prompt if something will be obsoleted. Just a special kind of upgrade (could be handled by the upgrade flag) `_unnamed_' - Prompt if a package name is not specified on the command line. It is very hard for an end user to understand this one, I see no need for this option `_dep_' - Prompt if a package is marked as a dependency. This is ok. `_skip_' - Prompt if a package was skipped (by --skip-broken). if a user adds --skip-broken then there should always be a prompt (if -y is not set) So no need of an option here. `_not_available_' - Prompt if a package was asked for from a repo. but couldn't be found (Eg. by load-ts or history undo/redo). It is very hard for an end user to understand this one, I see no need for this option `_not_installed_' - Prompt if a package was asked for from the rpmdb but couldn't be found (Eg. by load-ts or history undo/redo). It is very hard for an end user to understand this one, I see no need for this option If you put a `!' in front of any of the above single options, it will turn that option off. Eg. `!remove' or `!_skip_'. This is ok `none' - Never prompt (this is the same as assumeyes). This is ok `safe' - As though the user specified: remove,downgrade,_unnamed_,_dep_,_skip_ This is ok `all' - Prompt for any of the above cases (always). This is ok It is not deal breakers for me, but I like options to be easy and clear to understand for the end user, without knowing yum internals. Tim _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
