On 6/26/2012 2:40 AM, Kenyon Ralph wrote: > On 2012-06-26T00:44:12-0500, Stan Hoeppner <s...@hardwarefreak.com> wrote: >> On 6/25/2012 7:55 PM, Holger Levsen wrote: >>> On Montag, 25. Juni 2012, Stan Hoeppner wrote: >> >> cgi was the default in 1.4.x but one had the option to use cron. I >> chose cron because the particular machine isn't speedy. > > CGI graphing was not the default in munin 1.4. So, for most > installations, munin 2.0 is a significant change in this respect. > >>>> The upgrade installer is simply broken. This isn't the Debian Stable I >>>> know and love. >>> >>> backports is not Debian stable. They are supposed to work well, but they >>> are >>> much less tested than Debian stable. >> >> I've been using Debian since 2001 and backports since long before it was >> folded into official Debian. I know full well what it is and is not. I >> thought I already made this clear. >> >>>> My big complaint is that an 'aptitude safe-upgrade' shouldn't install a >>>> package upgrade that is so completely broken and does not work without >>>> major surgery. The backports repo is supposed to contain stable working >>>> packages backported from testing, or so I thought. And frankly I'm >>>> surprised a safe-upgrade pulls packages from backports. I was under the >>>> impression it only pulls from the stable repo. And, no, I've never >>>> modified any apt preferences or whatever to cause it to pull packages >>>> from backports. I don't even know how this would be done. This is >>>> something that happened automatically. > > I think you misunderstand what "aptitude safe-upgrade" means. No, it > doesn't mean it only pulls from a certain repository. It doesn't mean > that the packages are "safe" or tested or non-broken. It just has to > do with how aptitude resolves dependencies and decides whether to > upgrade packages or not. See the aptitude documentation.
I have no such misunderstanding of "safe-upgrade". I just didn't realize aptitude would upgrade bpo's automatically. I'd have preferred to discover this fact under different circumstances. Some lessons are best learned when the pain factor is high I guess. :( >>> no. I don't know which backports repo you are refering to, but if you >>> simply >>> add the sources mentioned on backports.debian.org to your sources.list of a >>> debian Stable system, I'm quite sure "aptitude safe-upgrade" won't install >>> munin 2.0 from backports unless you have done something. "apt-get dist- >>> upgrade" (and upgrade as well) certainly wouldn't (install any package from >>> backports.org for that matter). >> >> Did this happen because I was previously running a munin backport? >> 1.4.6-1~bpo60+1 >> So safe-upgrade automatically installed the 2.0.0.1 backport? > > Yes, if you have a bpo package installed, and there is a newer version > available, by default, the newer version will be selected for upgrade. > I find "apt-cache policy" very handy to see what APT thinks about a > particular package's versioning situation. Thank you for this pointer. I've never had to use this before, but it will surely come in handy now. >> If so, then please explain to me again why/how this broken upgrade to >> 2.x is my fault, a point you continue to attempt to drive home, when you >> developers knew the 2.0.0.1 backport doesn't work with lighttpd, >> according to you. BTW, the package information doesn't mention that >> Apache2 is required, nor that Lighttpd won't work. It simply says >> "recommends httpd": > > As you know from your 11 years of Debian experience, none of the > developers can test every situation. Of course not. And devs obviously aren't going to be using the backports system, so they wouldn't think to test such a scenario. > Indeed, this package came from > the testing distribution, and has not been in the stable distribution > yet. So, thanks for being a tester and pointing out some areas of > potential improvement. More like unwitting guinea pig. ;) But seriously, I'd be glad to assist further in any way I can. >>> for that you either need to explicitly say "apt-get install -t backports >> >> This is what I though as well, and has been my experience--if I wanted a >> backport package, I had to individually install with '-t' and the name >> of the repo. Did someone change the behavior of aptitude in this >> regard? It sure appears so. > > This behavior has not changed. You had a backport package installed, > so it was simply upgraded to a newer backport package. You must have > manually installed the 1.4.6 backport. If you use any other bpo > packages, you should see them receiving upgrades in your aptitude > logs. Yes, I did manually install 1.4.6 bpo. I'll check, but I'm pretty sure this is the first time this has happened. I was running a Postfix bpo and munin bpo, maybe another. The former both got upgraded this time with the newer bpo. Prior to now, I don't believe any newer bpo's were ever available when I upgraded, which caused me to have a false assumption about this upgrade behavior. >>> munin" or reconfigure apt/aptitude to grab packages from backports by >>> default, >>> which is not sensible. >> >> As demonstrated by the evidence above, I did neither of these two things. >> >>>> So what do I do now? Can 2.0 be made to work on my system? >>> >>> sure. easily with apache2 and with some work with lighttpd. >> >> Can you point me to a set of instructions? The ones for lighty I >> followed didn't hit the mark. Or maybe there's something else I'm >> missing that wasn't in those docs. > > Several munin developers and users use munin with lighttpd, so you > might find help in the #munin channel on oftc.net IRC. In the process, > with your help, we could improve the documentation and packaging of > munin and its integration with lighttpd. Thank you, I'll give IRC a shot. And just let me know how I can help. Feel free to contact me directly if needed. >>>> Or is it >>>> simply completely hosed? Should I file a bug report against the upgrade >>>> script? If so, how do I do that? What's the package name for it? >>> >>> aptitude, but see above. >> >> Given the information I presented above, which suggests munin was >> upgraded to the 2.0.0.1 backport due to the currently installed version >> being a backport, is the problem with aptitude, or with the information >> contained in the munin backport package itself? I.e. should the >> backport 2.0.0.1 have included a "reverse dependency" such that aptitude >> would not install 2.0.0.1 given that Lighttpd was the installed hpptd? > > No, aptitude and the package management system is working as expected. > >>>> I, the user, did nothing to break my munin. Fault lay with the >>>> developers. An upgrade shouldn't completely totally break a program so >>>> that it simply won't run at all, which is what has happened here. This >>>> is very frustrating to say the least. > > I can certainly understand your frustration. This happens to everyone > who does any nontrivial work with computers. All software sucks. But > this is what we have, and we try to make the best of it and > continually improve it. I wouldn't say all software sucks. In the long and short of it, Debian has worked very well for me for a long time, most packages working as expected most of the time. I guess it's just been a long while since the last time I had a package unexpectedly blow up like this, and the fact that Debian packages/management has worked pretty much flawlessly for me for a very long time. That's not to say I haven't blown things up myself, but I usually knew pretty quickly the cause, and who to blame--the guy in the mirror. ;) >>>> If this is not a bug, and a bug report isn't the proper place to receive >>>> troubleshooting assistance to get this working, where do you recommend I >>>> go for assistance? Please don't say "debian-users". I've been a >>>> subscriber for over 3 years. Munin is never discussed and there's >>>> likely no other munin users there who could help. >>> >>> the only munin bug I see here is "please add support for automatic >>> configuration with lighttpd" >> >> No, that's not the bug. That would be a feature request. Manual >> configuration is fine with me had a warning been given BEFORE the auto >> upgrade, and a link to docs that would yield a correctly running munin >> 2.0.0.1 on Lighty. >> >> The bug here is the automatic install of 2.0.0.1 onto a system with a >> configuration, according to you, KNOWN to not work with 2.0.0.1 >> automatically. I'm fine with manual configuration as long as I'm told >> up front that it's required, and provided exact instructions. >> >> The bug, therefore, is that the installer didn't check the current >> configuration for compatibility before proceeding. If munin 2.0 only >> works out of the box with Apache2, the aptitude should not have >> installed the backport on my my Lighty system. > > There, finally, in these preceding three paragraphs, THAT is a > specific, actionable bug report. The Debian packaging system can > provide such warnings upon installation, and perhaps munin should give > a warning, until someone is able to make munin integrate as smoothly > with lighttpd as it currently does with apache. > >> Do you disagree with these assertions? >> >>> and for that I'd prefer a patch or at least help, >>> as I'm not a lighttpd user myself. And for that I'd prefer a new bug to not >>> have this as irrelevant history to a simply request :-) What do you think? >> >> Irrelevant history eh? > > The best bug reports are concise, specific, and actionable. I think > that Holger's feeling, and I agree, is that this bug report was > originally too vague, and now has too much discussion to be useful for > working on a specific issue, and so for bug report management > purposes, more specific bug reports should be filed. Note this was in the first paragraph of my initial bug report: "...the installer should make clear to the user that manual modifications are necessary." That is not vague, and constitutes the bulk of this bug, as you agree above. So, should I file a new bug report simply stating: "Munin 2.0.0.1 upgrade process should check for lighttpd, warn user giving option to back out, and provide link to manual configuration information"? -- Stan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
