[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)



Hal Vaughan wrote:
> But does it address the original issue?  The original report is that 
> menu.lst is overwritten without notice.
>   

A fact that is noted in that file, by the way.

In the top, there are pointers to documentation on what interacts with
the file:
# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-doc/.

OK, that does not tell anything about making changes in the file, but
further there is also:
### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

Not the best wording, but certainly gives some hints, especially if
combined with the manual pages mentioned above.

> I just don't see why he didn't see that as an issue of importance and I 
> am a bit confused that everyone keeps talking about the comments in 
> menu.lst and other issues and all the other points in the bug report, 
> but that still leaves the point of the initial bug report.  Apt or dpkg 
> or something always warns us when it's about to overwrite a config 
> file.  Usually we get a 4 choice prompt, the same prompt every time.  
> Something like Y/N/K/R for Yes/No/Keep/Replace or something like that.
>
> So if rsync.conf or mdadm.conf is worth prompting the user before 
> overwriting, why not one of the few config files that the system needs 
> to even boot up?
>   

You're misunderstanding a point here. The files you mention are
configuration files shipped with packages. If a package ships a new
version of the configuration file, and the file has been locally
modified by the user, you get that point during package installation.
Grub's menu.lst, on the other hand, is not a file like this, it does not
get changed because it was shipped in a package, but rather because a
post-installation script by default calls a command to update the file.
Which is, in most cases, quite useful: most users, when installing a new
kernel, will appreciate it appearing automatically in the boot menu.

So there are two different situations here, handled in different ways.
The boot.lst file (or actually, a part of it) is meant to be updated
automatically. It is possible, though, to make changes to it and not
interfere with that automatic kernel detection. You just need to make
them outside the part delimited by "BEGIN AUTOMAGIC KERNELS LIST" and
"END DEBIAN AUTOMAGIC KERNELS LIST". It is also possible to disable
calling update-grub (the program that changes the file), it is document
in one of the manual pages listed in that file.

There are certainly ways of improving that (for example, stating more
clearly in the file that some parts of it get automatically rewritten),
but you seem to have some unrealistic expectations of how that file is
handled (though it may appear similar to rsync.conf, it is handled in a
totally different way). It is unlikely that this behavior will be
changed, no matter how you complain about it. In part because what you
want to achieve can be done, you can edit the default options that
affect all automatically included kernels, you can manually include
kernel stanzas with exactly what you need, or can you even disable
automatic update of the file and do all changes yourself.

-- 
Blessed are they who Go Around in Circles, for they Shall be Known as Wheels.

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br
http://move.to/hpkb


Reply to: