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. > > 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. > 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. 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. > > 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. > > 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. > >> 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. > >> 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. -- Kenyon Ralph
signature.asc
Description: Digital signature
