Whether or not a certain operation is OK is a yes or no question. There cannot logically be any third possibility. Furthermore I did research as to what the d could mean. I got conflicting information. The two main theories were that d stood for "download only" which is what probably makes sense and "default" which is not so likely as the default choice which is usually N is what's capitalized. The point is what the d stands for is a source of confusion even for users like me that have been around. For newer less experienced users this may be a turn off that sends them running back to Windows. This is bad for both the interests of Red Hat who I assume want to be known for ease of use/user friendliness and for the larger Open Source movement in general which needs as many people as it can possibly get. Also even if the d does indeed stand for download only that should be clearly stated in the prompt or at the absolute least the man page. The current prompt just flat out doesn't make sense from a logical perspective. "Is this OK?" is a boolean yes/no question. Not a yes/no/who knows what else sort of thing. Though more verbose a better prompt would be something like: Should this transaction proceed? Enter 'y' for yes or 'n' for no which is the default. Enter 'd' to proceed with the transcation but to only download and not install the packages that are targeted for installation. This will store them in the cache and make them available for later installation even without a network connection. Desired action?(y/d/N)
I have since verified conclusively that the d does stand for download only. Nonetheless I shouldn't need to do these trial and error experiences and the behaviour for such things should be clearly and explicitly documented.
s/experiences/experiments
I agree this might be confusing at first, but changing a 1-line prompt to a 6-line nag wouldn't be good either. I'd rather add a paragraph to "man yum" that you could easily grep with "prompt" or "y/d/N". Would that help?
Sorry for the late response. Anyway as far as changing the one line prompt to a six line prompt I do partially agree with you that it might be a nag but I still think it's an idea worth considering along with smaller changes. The fact of the matter is that yum is politely put quite verbose at times. As but one example of that whenever there's a transaction yum prints out pages upon pages of spiel as it calculates dependencies. Sometimes this can be useful and this certainly can give users transparency and insights into problems when things go wrong. However it really is largely unnecessary in most cases because before the y/d/N prompt it writes out a nice well organized chart of what will be installed, removed, updated for dependencies, from which repository, version number, etc. My guess as to why yum prints out the pages and pages of its dependency calculations is because since yum isn't exactly known for its speed yum is attempting to show the user that it is indeed doing this or that calculation and is not frozen/hung up. Anyway my point is that yum is verbose in quite a lot of instances and the six line prompt will hardly look out of place. In fact it may give yum a more consistent integrated feel as right now yum is overly verbose in some cases and quite uninformative in others such as this one where users have to guess what the d means. Now I do agree with you that needlessly verbose prompts can be annoying and that it is a good idea to think twice before doing changing a one line prompt to a six line prompt. Though I am leaning towards the six line prompt thing I'm not sure that the idea should be acted on. All I'm saying is that it's a legitimate idea that shouldn't be thrown out yet and that it deserves some serious consideration. Also maybe there's a more compact one line prompt that will be almost as informative. A few possible candidates are: "Is this OK? (d to download only) [y/d/N]: " "Proceed? (y)es, (n)o, or (d)ownload only. [y/d/N]: " "Proceed? (d to only download packages that would be installed) [y/d/N]: " Even the longest of these is only 72 characters which is less than the 80 that are available on some really old consoles with limited screen space/resources. The point is any of these are quite short, portable across many systems, and worlds more informative than the current prompt. The one I put last in the above list is the prompt I like the best as it is the most explanatory. Also the six line prompt is not an idea that I think should be discarded prematurely because not only is it informative about what the d does but it also explains why someone might want to use the d which is of course to have the target packages available for installation even without a network connection. As far as putting in a paragraph about this in the man page I think one should absolutely be put in. Keep in mind though that while this may help experienced users to quickly find the information they seek changing the prompt to something more informative is still necessary to help newer users. Newer users just aren't as used to looking at manual pages. Even if they were this is just one of those obscure things which no sane user even an experienced one will have reason to believe is documented in the man page. If you think about it from the psychological perspective of a user whether experienced or otherwise most of the interactive command line programs they've used have very clear self explanatory prompts. Rarely if ever has a user had to look up what exactly a given prompt means in a man page. The program usually just states what kind of input it needs and what the user's options are right there on the spot and the user goes from there. Man pages are great for describing a program's general operation and the intricacies of what various command line arguments and configuration options do. In fact they are usually used for precisely that. I've never seen them used to describe what a given prompt means. Also users who are running the given program for the first time or even veterans invoking a known program in a different way usually have absolutely no idea what they'll be prompted for or at best a somewhat foggy guess. Having to look up what the prompt means mid invocation is just a pain. In a graphical environment it's not so bad. As for users without X they'll need to switch to another virtual console, type in their username, password, etc which is quite annoying. Granted this can be overcome by using Tmux or something of the sort but still at the end of the day a user having to look up what an interactive prompt means in a man page is both counter-intuitive and annoying for both newbies and experts alike. Please consider these points and let me know your thoughts.
Thanks for your comment. I've proposed to change the prompt to the last proposed variant, just dropped the "that would be installed" part because that's inaccurate (updating, downgrading, and obsoleting packages are downloaded too), and it's probably obvious we will download packages that are needed for the current transaction and not yet cached. 'Is this ok (d to only download packages) [y/d/N]: ' The downside of changing the highly visible localized strings is that the old translations won't be used, and users see the untranslated strings instead. It takes up to few months until voluteers complete the translations and we release it.
The prompt you proposed seems to be quite nice and does clarify things a lot. Thanks for putting it out there and for your help in this matter. Hopefully translations go fast and your change will land in yum soon.
Created attachment 828626 [details] Proposed initial patch for the man page This would deserve reflection in the manual as well.
Agreed. The more places this is clearly documented the better.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.