[Yum-devel] "doastold" option, or, putting code where my mouth is

[Michael Favia]

seth vidal wrote:

>On Tue, 2005-03-08 at 23:21 -0500, Matthew Miller wrote:
>  
>
>><https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=418>
>>
>>As part of the building and testing I do for work, I add and remove packages
>>pretty much all day long. So I get prompted by yum a lot, which gets
>>tedious. However, I sometimes *do* want to be prompted -- like, when
>>something I didn't expect is about to happen. So, it'd be nice if there were
>>a "doastold" option, which would make yum not prompt when the action to be
>>performed corresponds exactly to what it was told to do, with no additional
>>packages added or removed.
>>
>>I think this is actually *safer* than being prompted every time, because one
>>gets in the habit of saying "yes" to everything without double-checking. If
>>the prompt only comes up when there's really something to check, it's much
>>more effective.
>>
>>Bugzilla link above has a patch which implements this. The option is off by
>>default.
>>    
>>
>
>
>Like I mentioned when I closed the bug: This makes the interface
>horribly inconsistent. And by adding an option you're just adding a
>feature someone may turn on that creates an inconsistent interface.
>
>Other than apt can you think of any program that implements a "confirm
>occasionally" interface?
>  
>
I recognize your desire to create a "standard user experience" so that 
someone using yum knows what to expect and i agree wholeheartedly. 
However this isnt "confirm occasionally" (which sounds whimsical) this 
is "confirm if things that i didnt explicitly command are going to 
happen to accomplish the thing i DID explicitly command" (which sounds 
rational). As others have mentioned and could go on mentioning there are 
a number of useful places where just such a  confirmation is desirable 
and present. An argument could be made to confirm all removals (like the 
confirmation of all filesystem removals without -f) because of the 
immediate harm they could cause. You know what to expect if you copy a 
file intro a directory with an already present file of the same name right?

Example:

[michaelfavia at hydrogen michaelfavia]# touch test.txt
[michaelfavia at hydrogen michaelfavia]# touch /home/test.txt
[michaelfavia at hydrogen michaelfavia]# mv /home/test.txt .
mv: overwrite `./test.txt'? n
[michaelfavia at hydrogen michaelfavia]# rm test.txt
rm: remove regular empty file `test.txt'? y
[michaelfavia at hydrogen michaelfavia]# mv /home/test.txt .
[michaelfavia at hydrogen michaelfavia]#


While i recognize the need to fire the "no" gun very frequently to keep 
the noise down and get real work done i think this idea deserves more 
consideration than it was given and thank Matthew for mentioning it.

-mf