On Saturday 11 October 2008, Andrei Popescu wrote: > On Sat,11.Oct.08, 10:20:57, Hal Vaughan wrote: > > [...] > > > I still maintain that the issue had more to do with the issue than > > the response said, however in that case, but I felt the responder > > was more interested in writing it off than in dealing with the > > issue or helping me figure out where the bug should have been > > categorized under. > > Sorry Hal, I have to disagree here. Aptitude is just a package > manager frontend, it doesn't have any responsibility whatsoever about > what maintainer scripts do on your machine (in this case it's the > scripts of linux-image-*). You would have triggered the same > behaviour by 1) using apt-get instead of aptitude[1] 2) > dpkg-reconfigure linux-image-*.
Just yesterday I installed Etch on a new Soekris box that I had to use LILO on instead of Grub. While adding the packages I needed on it, it kept holding back a kernel image until I installed it specifically and only that one package. When it installed the kernel, I got updates on what was going on, including when LILO was being run and what configuration files were replaced. The following may sound snippy, but I'm just trying to make the points I feel are important. I'm not trying to jump on you, but I'm also trying to get this out quickly because I have to be somewhere soon. If it sounds snotty, it's because I need to send it out now, since I may not have time to finish it for a day or two, depending on a family member's health situation. Now, granted, I've been making my living as a programmer for about 7 years now, but on the flip side, like many of us, I don't have time to study the code of every package I use. In that case, I ran aptitude and didn't get any, "Overwriting menu.lst" message, but many times I run aptitude and get a choice of whether or not to overwrite a config file or keep my current one. Now, as an end user, how am I supposed to know if these messages are coming from Aptitude or the script in the package? Am I supposed to comb through the code and find out that it's not aptitude but a script it runs? I'm sorry, but at the time I was spending most of my life trying to get my own business in good shape as well as working with my Mother to care for my Father, who was dying of leukemia. While that isn't directly connected to the bug report, the point is that I'm TRYING to help by saying, "There's a problem here." I don't have time to come through the inner workings of apt or aptitude and neither do many who file bug reports. His (Christian's) comments were "This has nothing to do with aptitude." Then he goes on to talk about update-grub and that I asked for it. No. I didn't ask for it. I remember that situation enough to remember that one reason I was frustrated was I did what I thought was a normal upgrade and didn't specify other programs be run. If it was run, it was run by aptitude or a package script (speaking from my perception now). Then he goes on to tell me about the postinst_hook and postrm_hook. At that point I'm wondering, "What the heck are those? Why do I care? Why is he telling me this?" I don't know if he's just trying to dazzle me with bs or to make me feel like an idiot because he knows so much and I know nothing. What would be wrong with saying, "It wasn't aptitude that did this. It was a package you were updating, which could be the kernel or grub itself, and the bug would pertain to one of them."? When I finished reading his comment I still had no idea what was going on. I had no useful information. I said, by filing a bug report, "There is a problem here." What do I get? Basically, "Well, it's not my problem. Everything here did what it should." I get comments on hooks, but nothing clear enough to tell me what to do to report this actual problem. Just reasons why I'm in the wrong place. He had one useful suggestion, which was to read the comments in menu.lst, however, look at that file. Look how much info there is. I was changing an option in the automagic kernel list and had read comments around that area. I had no idea or reason, originally, to think that if I made a change in that section, I also needed to read all the other sections as well. Like many of us, I'm self taught in Linux and have read, by now, a few thousand man pages. If I had read each one all the way through whenever I needed something new, I'd still be reading them and my business would be nothing but paperwork downtown. We can't know all the issues with every program or package we use. Yes, in this case, that was helpful. Then on the next comment from him, the only comment that might be helpful at all is, "I guess that the update you made installed a new kernel image...which trigger an update of the grub menu file when the postinst script of the kernel image package is run." Actually, now that were discussing this, I find that helpful and frustrating. Again, I'm saying, "Something is wrong," and he's saying, "It's not my job." Then he says he thinks this is what happens. Now he's someone who knows the inner workings and I had already said basically what he just surmised, but at least he sees my point. But rather than pointing me in a direction that would help me know what to do, he continues with, "Then something else changed it...but I have no idea what did so. The file does not belong to any package. Certainly the bug is not, definitely not, an aptitude bug. You can't blame aptitude for every problem happening with packages it installs." Do you see why I feel like this was a waste? I took the time to write up a bug and explain what I could. I don't know apt or aptitude. All I know, as someone who uses those programs, is that I ran one and it borked my system. All I get in response is, "Nope, not my package. Something else, but not mine." So what did I gain? Did he even give me a list of suggested packages that might have caused the problem? All I knew is that a package is a black box. Now I know there are scripts with them that run different programs, but I have no idea how to figure out which one would have created the problem. As I said, in all other cases, when a file is overwritten, I've been given a choice or warning and got nothing here. As a reporter, that's what I know. What he said in response was either over my head or totally useless. Re-read the report from the point of view of someone who doesn't know the inner workings, who is not a DD, and then ask yourself, "If I didn't know a thing about apt, and filed this report to try to save others from this problem, would I find the developer's responses helpful?" I think you'll come to the answer I did: they're not helpful, they don't give me any idea where to look next and in some cases, like when he's talking about hooks, he goes straight into the heavy tech stuff for that particular program that just leaves me confused. I respond, trying to get more info, and the basic response I get in return is, "It's no my job." So what was the point in filing a bug report? And with responses like that, why try filing another? > As for the response of Christian Perrier, I'm sure he didn't mean to > be rude[2], it's just that the tone is hard to replicate in writing. And I'm supposed to know this --how? Okay, I'm being snippy with that comment, but there's a reason for it. The point has been made that I need to be nice in bug reports, but there's a flip side, and that flip side was my point at the start: a developer responding to a bug report has to be nice as well. That includes knowing that the bug reporter may not know the program well or know all the technical details. That means telling them, in terms you are SURE they'll understand, just what is going on. Remember Stargate SG-1? Remember how Carter would get into a tech explanation and O'Neill would say, "Carter?" and she'd give him a 1 sentence explanation anyone could understand? It's the same here. don't assume the reporter knows all the tech stuff, no matter what their level. It also helps, if you're saying, "The problem is elsewhere," to at least give the person an idea where to go. It does NOT help, at all, to do nothing more than say, "No, the problem isn't here." Then I don't know if he's being conscientious or if he's just trying to close out the bug report. I got the strong feeling he just wanted the bug closed and wanted me to go away. Again, re-read the link from the point of view of someone who doesn't know a thing about the inner workings of dpkg or apt and see if you don't get the same feeling. It's like he's basically just giving me a list of reasons why it's not his problem and makes no effort to tell me who's problem it is. > [1] actually dpkg is the one installing packages and running the > maintainer scripts. AFAICT apt[itude] just feed it a list of packages > to install/remove/whatever. And it would have helped if I were directed there or at least told, "It's likely grub or the kernel package or the kernel source package..." Again, I don't mean to be short, but I have time limits and, unfortunately, that also means it's easier for me to just write a longer reply with all the points I have than to edit it and shorten it. If things go well and I have more time this weekend, I'll be glad to discuss it more. I do appreciate that someone cares enough about my point that it's easy to discourage people from filing bug reports to discuss it. Thanks for the interest in the subject. Hal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
