Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Tuesday 14 October 2008, Eduardo M KALINOWSKI wrote:
> 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.)
Yes, at some point I had changed it. Why or what the change was, I'm
not sure of at this point. I should have said I had edited it, but I
guess I was focused on what I specifically did on "D-Day". I also
thought it was "standardized." Why? I don't remember, but when I go
through and make changes and have to experiment, I'm pretty picky about
making sure things are all cleaned up when I'm done, but two years
later I can't state positively I had, at that point, existing changes
(intentionally) or the exact state of the file.
> 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.
This I understand now and if, in the bug report, he had said that, just
as you said it here, then it would have made a big difference to me.
That's ALL it would have taken. Now that we've gone over it and bled
the original report to death, and people have commented, I can see how
he was trying to point me to it, but as someone who knew nothing about
the inner workings of apt -- and, as with most people, really had no
desire to know about it, I wasn't clear on what he was doing.
Again, I think if you read that initial report from the view of someone
who does not know much about apt (or maybe grub?) then I think one can
see where I got the impression he was basically trying to say, "It's
complex, but it's not my job." If he had used that paragraph above,
except for your last sentence, then most of what he wrote would have
been unnecessary. All that I would have wanted after that was info on
how to figure out which package it was.
I would say, and this is getting picky (perhaps), that the actual bug is
in what calls the update-grub script. Instead of just calling
update-grub, a script could have said, "This update will
re-write /boot/grub/menu.lst. Press return to continue." That would
have been enough (although giving a choice of continuing or not would
have been nice, too).
> 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.
I agree that it's a good way of doing it. But how hard would it be to
not call the program directly, but call a script that prompts, THEN
runs update-grub?
> [0] I say was because it happened two years ago, and most likely has
> already been fixed by now.
I don't know and I just make sure if I'm experimenting with grub, that I
backup /boot if I have to use apt at all. I gave up on trying because
I felt like what I said was just talked over. That may not have been
Christian's intent in the response, but it's what I felt like what
happening.
> > 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.
I see the point of how and why it's overwritten, but still maintain a
bash script with a warning would be appropriate.
> > 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.
Remember, this whole discussion got started because of my comment that I
used to file bug reports because in the past I've found that they
either led nowhere, the dev closed it out as quickly as he could
rationalize it, or in some cases, the responses were hostile.
I support FOSS, financially, by helping in other projects, and by
offering some projects I've done on my own. But I've given up on
filing bug reports because I never saw one I submitted lead to a
positive experience in terms of a developer responding to the bug to
fix it or otherwise.
> > 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).
But it's even more important than many of the files in /etc. How hard
would it be to use a script that warns whenever it's about to be
overwritten?
Hal
Reply to: