Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Monday 13 October 2008, Eduardo M KALINOWSKI wrote:
> 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.
*SIGH*
You don't get it, do you?
> > 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.
No, you are. You've missed it 100%. Explanation below:
> 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.
Yes, they will appreciate it, but the point is you run some version of
apt and a file is overwritten.
> 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.
Thank you for proving my point!
You are getting so sucked in to the minutiae of the situation that you
are not hearing what is being said.
You may know that there are two different situations, but most users
will not. As a user, you run apt and get notified that important files
may be changed. Unless you have gone through all the man pages or all
the docs, the difference you're talking about is one most people will
never see and, honestly, will never care about.
An "end user" of apt isn't going to care if the file was added as part
of a new version or was written by apt. There *IS* no difference to
the user. A critical file is gone. How is irrelevant and few people
will ever catch on to the subtle difference you mention and even fewer
will care that there's a difference.
You've basically proven one of my points: that if you know a system or
program, you can get so caught up in arguing a point that doesn't
matter to the person filing the bug report that you miss the point.
> 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.
You just don't get it, do you?
For instance, stating it in the file: Again, not everyone has time to
read all the comments in all the files. As to unrealistic
expectations, what would be so hard with using a bash script specifying
the rewrite was going to happen? It's not that hard.
I don't mean this with any offense, but you're so wrapped up in the
details you're not seeing what's going on. You're re-arranging the
deck chairs on the Titanic.
Hal
Reply to: