On Tuesday 14 October 2008, Eduardo M KALINOWSKI wrote: > Hal Vaughan wrote: > > Instead of just calling > > update-grub, a script could have said, "This update will > > re-write /boot/grub/menu.lst. Press return to continue." That > > would have been enough (although giving a choice of continuing or > > not would have been nice, too). > > [...] > > I see the point of how and why it's overwritten, but still > > maintain a bash script with a warning would be appropriate.
Aha! Now we are talking about the original issue -- or at least the original one in the bug report. Thank you! > I disagree. Installations should be made in order to be as automated > as possible, prompting the user or stopping in any way should only be > done in really important cases. > > I think that such a warning is unnecessary, because it is not > relevant in most cases. The automatic overwriting of some parts of > the file will only render the system unusable in two cases: > > a) The update-grub has a bug and does something it shouldn't. This > can happen, though is certainly not something common or expected. And > even so, such a warning is superfluous: it would be the same as if > your mail program warned, before each time it downloads mail: "I'll > download new mails and change the contents of your inbox, so please > make a backup of your mail files now, and then press ENTER to > continue." Not quite the same. Mail is downloaded many times a day. How often would update-grub be run? > b) The user has changed the menu.lst file manually. In this case, the > user should probably have noted the warnings and pointers to > documentation that are present in that file, in which case he should > already be aware of the automatic calls to update-grub. And provided > he does not change a few specific parts of the file, it is perfectly > possible to edit the file, and changes will be preserved even after > update-grub. But then, at that point, there is still no warning supplied. He may or may not be aware of the automatic calls, but most likely won't be. That leaves a system coming up for reboot that won't and the user doesn't know why. > Moreover, not-so-experienced users would be confused by a prompt > about changing that file, a probably they likely don't know nothing > about. If they've changed it, they'll get the prompt, if they haven't, they wouldn't. So the only ones that are confused are those that changed it and don't remember changing it. This argument would also apply to *ANY* configuration file that has been changed at all: don't warn the user because it'll confuse them. The same arguments that apply to user edited config files would apply to this config file. It'd be just as confusing or not confusing as any of the other prompts. > While I think no OS should get in the way of advanced users > doing advanced things, new users should be kept in mind. And all the > power is given to advanced users that want to deal manually with the > Grub configuration, including the ability to disable running > update-grub, or run another script instead. Okay, but you're leaving out those who know more than the complete newbie and those who know the system well, which is a LARGE amount of the user base. So maybe you don't want to confuse people by giving them a choice. There's still the possibility of at least including a way to check if the file's been edited, the same way any config file is checked (I don't know how they do it but can guess) and if it has been changed, reporting, "Grub has been edited since it was last updated. Please be aware that it is about to be overwritten by update-grub. If there is data or settings in it you need, we suggest making a backup now." Then you can either wait for "<enter>" or give a countdown -- or even save it to a backup automatically, making sure it's copied to a unique name, like menu.lst-bak.0001 or .0002 or whatever the first unused number is. Obviously I disagree with you on this, but at I'm glad we're at least talking about the specific issue instead of everything near it. Hal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
