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

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



On Mon, Oct 13, 2008 at 11:21 PM, Eduardo M KALINOWSKI
<eduardo@kalinowski.com.br> 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.
>

Um, I think you've completely missed the point here. It's not like the contents
of menu.lst is presented to the user on upgrade (nor should it be), so the
content of that file is irrelevant.

>> 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.
>

I believe you have very well illustrated the point that the user and developer
have different perspectives. Anyone who already knows this would have filed the
bug differently - but why in the world would anyone need to know such a fine
technical detail? The user of a software package doesn't usually care about
implementation details like this. In this case, inconsistent handling of
critical configuration files should probably be considered a bug regardless of
the reason for it. If manual (or scripted) changes to every other configuration
file cause a prompt, then they should for this one too. Saying "this one's
different because of <technobabble>" doesn't address the issue at all.

Anyway, I thought this was worth talking about because it seems there are a lot
of bug reports in which the reporter sees a forest but the developer (or
whatever) can only see the trees, and they both go away thinking the other guy
is both rude and a moron, which is unfortunate to say the least.

-Nye


Reply to: