Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Mon, Oct 13, 2008 at 17:36:25 -0400, Hal Vaughan wrote:
> On Monday 13 October 2008, Florian Kulzer wrote:
[...]
> > I only wanted to point out that there is a direct logical line from
> > the replies to your bug report to the relevant documentation.
> > Therefore I think that your complaints about not receiving any help
> > at all with your problem are unjustified.
>
> But does it address the original issue? The original report is that
> menu.lst is overwritten without notice.
I am not denying that this is a valid issue, I am just arguing that it
not a "serious" (according to the BTS definition) bug because:
- AFAIK, running update-grub after every stock kernel upgrade is
intended and the default configuration on a freshly installed system
(if grub is the chosen boot manager)
- the "typical non-geek end user" will not want to mess around with
menu.lst anyway, therefore update-grub not only does not harm him/her,
but it is actually needed to make sure he/she gets new boot menu
entries when necessary
- menu.lst provides specific mechanisms to allow customization of this
file without having to fear interference from update-grub at any later
time
- the procedure is documented in the comments of menu.lst and in the
manpages mentioned
- the hook system provides any easy means to keep update-grub from
running altogether or to replace it with any other script of your
choice
Nevertheless, all this did not work as intended in your case. After it
had been pointed out how you can prevent update-grub from running again,
there remained your suggestion to add an explicit warning or a yes/no
dialog to the process. That, while being a point worth considering,
strikes me as belonging to the "wishlist" or "minor" category, and
therefore I think it is acceptable if it is given a much lower priority,
depending on the overall workload of the person(s) in charge.
(Side note: The kernel postinst script is more explicit about what it
does nowadays; I cannot recall when this feature was added, though.)
> How many times have you run apt-get update && apt-get upgrade and gotten
> notices about a config file in /etc being overwritten? You get notice.
> So why not for a file that's just as important, and maybe even more
> important?
As I said above, I agree that it is a good suggestion, but not one with
"serious" priority.
> While I made my point on this, perhaps I shouldn't have since the whole
> issue of documentation on menu.lst still skips the primary issue of the
> report: An important config file is overwritten without notice or
> consent.
I think the quality and location of the existing documentation is
relevant for determining how urgent it is to address the silent
execution of update-grub. That is the reason I emphasized this point.
> So you don't see overwriting an important config file -- one that can
> bring down the entire system, as a problem?
As I tried to justify above, I see it as a relatively minor problem in
this specific case. (My main intention is not to argue about this with
you, but to explain why I think that the reaction to your bug report was
appropriate.)
> 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.
He did not dismiss the issue, he left the bug open for more than one
year. Maybe he was convinced that he had given you enough information to
know how to proceed, should you come to the conclusion that the dialog
is really necessary after reading up on the documentation that he
pointed out in his last reply.
> 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?
That is probably a matter of taste; some people might prefer a "just
give me a well-commented config file and get out of my way" type of
system.
> I didn't go to lklm or anything like that because it's not an issue for
> them, which I think is quite clear. It's an upgrade issue.
Ah, I did not realize that the statement about the kernel development
list could also be understood like that; I am pretty sure he meant the
debian-kernel list, which deals with the Debian kernel packages and is
therefore responsible for the postinst scripts.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Reply to: