[Yum-devel] [PATCH 2/2] Add documentation for assumeyes change.

tim.lauridsen at gmail.com tim.lauridsen at gmail.com
Tue Jul 12 07:45:50 UTC 2011


On Mon, Jul 11, 2011 at 8:40 PM, James Antill <james at fedoraproject.org> wrote:
> On Mon, 2011-07-11 at 19:05 +0200, tim.lauridsen at gmail.com 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
> Yum-devel at lists.baseurl.org
> 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


More information about the Yum-devel mailing list