Hal Vaughan escreveu: > It was two years ago. I don't remember all the details, but basically I > did something like "aptitude update && aptitude upgrade", got a new > kernel image, and a clobbered menu.lst and it took me hours before I > got the server up and running. The system worked fine until I > upgraded, then it wouldn't boot. I had no idea why and finally tracked > it to a re-written menu.lst. >
Well, I had assumed that you had manually edited the file, if not for anything else, at least for the fact that you expected the prompt one gets when some configuration files in /etc are changed and the a newer version of a package wants to install a new file. (If the configuration file has not been changed by the user, then the new file provided by the package is installed and no questions are asked.) If you did not change the file and installing a newer kernel made the file unusable, it was a bug[0]. However, it was not a bug in aptitude or any other package manager, but of the package responsible for updating menu.lst. Moreover, it was not a bug because the prompt you expected was not shown, but because the update-grub script did something wrong. There are certainly several ways to deal with Grub's menu.lst, but Debian chose that specific one, basically of automatically updating the list of installed kernels, while allowing changes in the file, provided they are done in specific cases. I daresay the automatic updating of the list of kernels is a good thing and what most people want, and since it can be turned off, I don't really see much problems with that approach. It's not the only valid one, for sure, but even if it has caused problems in some circunstances, this problems can be solved by fixing the script that was not working correctly. [0] I say was because it happened two years ago, and most likely has already been fixed by now. > But, again, this misses the point: I don't file bug reports because, in > my experience, they either don't go anywhere, they are closed out as > quickly as possible with whatever excuse can be drummed up to justify > it, or, in some cases, the dev can even get insulting. > > I did not bring up this bug as an example, someone else did. However, > since it was brought up, my point was that I had a strong point: > Someone can use apt or aptitude and has every reason to expect prompts > before files are overwritten and in this case, there's no prompt or > warning. That leads to menu.lst being clobbered without notice. > However, as I said, it gets overwritten in a valid way. What happend is that something (which we will probably never know exactly what was) caused the file to become invalid, and this was a bug. Under normal circunstances (and I can say that from personal experience, I've updated kernel packages several times) the automatically updating works fine. > My point from the start was that, in my experience, bug reports are not > productive or worth my effort. Well, if you do not want to report, it is your right. But I'm glad other people do not share this point of view. > This one is not a top example, but it > demonstrates the point and the fact that, when it came up, most of the > discussion has not been about the file being overwritten but about the > contents of the file. > > That's why I feel many people don't get it and are missing the key > point. I do not want this to sound bad, but I think you have unrealistic expectations about that particular file. It is different from most other configuration files in /etc. It perhaps could have been handled in a different way, that's for sure, but it was chosen to work in a specific way (automatic updates of the contents to include (or removed) installed (or purged) kernels). While it is not expected that everyone knows that, it was pointed out where you could understand how Debian handles that file (and how to change that, should you want to). -- Eduardo M Kalinowski [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
