Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 05:40:29PM +0000, Martin WHEELER wrote:
>
> > He upgraded
> > from a Potato 2.2r2 system to current "testing" and most things broke in serious
> > ways, such that he swears he will never again move from stable releases.
>
> And *how*.
>
> NEVER again. (Certainly not for client-critical systems.)
>
I don't need to comment on that. Other people already have.
> On attempting upgrade to testing, first thing I was presented with was a
> decision to >>remove<< 402 Mb of system files (452 packages).
>
Yup, testing is somewhat messed at present (that's not intentional, needless to say). You should probably have guessed that something was very wrong... you realise that the developers aren't actually out to break your system?
> This I declined; and proceeded to (re-)install packages individually
> from an apt-get --just-print dist-upgrade list.
>
See "put package on hold"
> Things started to break/dependency-loop almost immediately.
> (The persistent offenders I remember most at this stage are exmh and
> kdeadmin.) The dependency circus engendered was horrendous.
>
Yeah, that happens sometime. It's a beta-quality distribution.
> Everything that was not "Debian-approved" got blown away.
> (I run lots of non-free stuff on my Debian systems. I have no
> ideological problems with this.)
>
Uhhh.... no. Read the social contract. Debian carries non-free and contrib, there's no attempt to force you into using free packages, only repeated encouragement (see vrms). What happened was that everything which was fulfilling one of these two categories got removed:
a) package was dependant on something which was removed due to the testing mess, see above.
b) package was =version dependant on something in potato (bad packaging/bug), so you would need to either find an official debian version, or one built for woody (testing) - you can't usually run packages from one release on another safely unless you know exactly what you are doing (recompiling from source into a new .deb will do the trick)
> I was no longer able to go online. (diald had been installed -- without
> asking -- on top of pppd.)
>
Oops. That one is probably a bug.
> > Mailman configuration broke
> -- due to fact that ALL apache confiiguration files/directories were
> simply annihilated. Again -- no warning; no explanation.
>
Never used it myself... possibly another bug (hey, it's not called "stable" for a reason)
> > Pine broke
> -- discovered that something had reconfigured my smtp server (wasn't
> asked; wasn't warned -- just another example of the "Debian-disapproved
> -- therefore OK to blow away" syndrome experienced throughout this
> whole attempt to upgrade.)
>
Far more likely is "not supported in debian due to licensing issues". Debian is not permitted to redistribute (modified) pine binaries. This kind of means that developers are disinclined to explicitly test it... although in this case, I'm guessing it wasn't pine related. Did you reconfigure the smtp server manually somehow? I'm guessing that you modified a configuration file directly when you should have used debconf/a source file (see /etc/modules.conf vs. /etc/modutils - suggestions on what could have caused this anyone?) and debian assumed that the changes to the config file were not of your doing, so put it back how you had told it (or not told it) you wanted it.
> > Mutt works, but is not his preferred option.
> Yeah -- but it's "Debian-approved", innit?
>
Will you quit with that? Read the social contract already.
> > Exim configuration didn't, such that he reverted to smail.
> -- conflicted with mailman -- not flagged.
>
> > He won't believe me
> > when I say that Exim works fine.
>
> [Not for me it bloody well doesn't. Not after *this* upgrade.]
>
Factoid from apt, a bot on #debian:
Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific!
> > Most seriously of all - "Apache in Debian is seriously broken"
> >
> > There may be a dependency loop on apache-perl which is inappropriate.
>
> This is the real crux of the matter.
> I CANNOT recommend this type of upgrade to any of my clients.
> My existing apache configuration was totally wiped out.
> Conflicting and inconsistent dependencies between apache and apache-perl
> prevented re-installation.
> (I eventually managed it by forcing something -- can't remember what,
> now. I ended up with apache-ssl; and a version of apache-perl that
> still can't be purged.)
> This would be instant death to any of the clients I deal with -- I am
> not surprised that some of them ban debian entirely.
>
dselect is arcane... dependency loops can be broken... or you can use dpkg --set-selections... apache-perl has been known to have problems, but you most certainly can force uninstall it... I am not suprised you have troubles with testing - it's not for those who don't understand how to use the packaging tools to fix things when they break. Rather than just flaming the developers, have you considered asking for assistance?
> > The default configuration of apache has changed drastically between Potato
> > and testing.
>
> There was obsolutely NO warning given that existing apache configuration
> files AND directories (including error log directories) would be
> obliterated. (I lost everything -- *including* my safe backups of all
> configuration files) when apache was upgraded.
> >> The infuriating thing is that I didn't even get an upgrade to Apache
> 1.3.12 -- which every other distribution has been supplying since
> mid-2000 -- I got the same old 1.3.9, but this time with a single
> httpd.conf in place of the previous 3 separate files. <<
>
> None of my scripting examples worked -- I had to spend three days
> reconfiguring the whole website. Not funny.
>
OK, if the directory was obliterated, you must have purged it. dpkg *will not* touch files it didn't create if you use remove. I'm guessing that you purged an old apache, and installed a new one. apt runs the purges before it runs the installs, so it first removed all your old config files, then installed a new set from a new application. It appeared to overwrite them, but I think you really wanted to remove one and install the other... "remove" is there for a reason, don't *ever* use purge unless you mean "I have no configuration files that I wish to keep"
> > The version in testing is locked down solidly - everything is
> > denied unless explicitly allowed with apache directives. This is at odds with
> > the behaviour up to and including potato, which was open. Apache stomped over
> > his httpd.conf files on upgrade and left him wondering what _exactly_ had
> > happened. As he says "All other distributions work out of the box. When I'm
> > training, I can get a class working on apache immediately." We both recognise
> > the need for security but he suggests that Debian is "too techie" in this
> > respect at the moment. Can we, at least, recognise the upgrade problem and
> > provide a choice "secure, preferred but hard to configure" and "you have an opensystem which may have holes but you want it that way" and preserve the existing
> > setup if the upgrader wishes?
>
> Only *some* of my clients would have been able to tackle the horrendous
> breakages caused by the new httpd.conf file's attitude to strict
> security (compared to the old lax attitude) on existing local website
> material -- I suspect that most would have immediately banned debian
> from their sites for evermore, and gone straight back to SuSE.
> No joking.
>
If they aren't able to tackle breakages, they should be running stable. Since we have a distribution called "stable", it seems pretty obvious that the later ones aren't. Go figure.
> My current situation is:
> -- after 10 days *hard* work I've got everything (almost) back to where
> it was, but upgraded. Sort of.
>
> HOWEVER --
>
> - I can no longer use dselect (because of the apache-perl conflict --
> it just runs amok and re-deletes apache for me by trying to purge
> apache-perl);
>
Read the documentation on dselect. You should be able to get out of this with judicial use of Q. Failing that, you can just edit the dependencies by hand with dpkg --set-selections.
> - Nor can I use apt-get upgrade -- at one point my kernel image was
> upgraded (thus forcing me to re-compile to get sound and a few other
> essential modiles back) -- and every time I now try to upgrade I get an
> insistent attempt to upgrade my kernel image yet again -- what the hell
> do I have to name it to stop this behaviour?
>
apt-get install kernel-package
Then read /usr/share/doc/kernel-package/README.gz
Failing that, you need to call it something that's not "vmlinuz" or similar. Otherwise you are overwriting a file in a package, which is never a good idea (will be automatically restored to an uncorrupted version, which is sane behaviour).
That said, you don't actually *need* a kernel-image package installed for most things... I recommend using kernel-package, though.
> - kdm and xdm don't work. I get a pretty login screen; log in; and get
> re-presented with the pretty login screen.
>
Read the documentation on kdm and xdm. I suggest you write a ~/.xsession. Also, apt-get install task-x-window-system, apt cannot cleanly upgrade potato xf3 to woody xf4 unless that package is installed (known issue).
> - xf86cfg puts me into twm. (Huh ???)
>
Try xf86config. Or dpkg-reconfigure xserver-xfree86. Or even just X -configure, and write the file yourself. I've heard of people having trouble with xf86cfg.
> - XF86Setup now warps my screen to an unreadable state -- always.
>
Yes. XF86Setup is for xf3. woody/testing has xf4. Go figure. Use one of the two tools above.
> (I have to demonstrate all of above to clients, to show the versatility
> of debian. Great with stable. Currently *infeasible* with testing.)
>
Yup. See all comments on "testing is not stable".
> OK -- I tried.
> Nice one. Thanks a bundle.
>
No charge. Ever.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s:-- a--- C++++ UL+++ P+> L++++>$ E++> W++ N++ o? K- w---
O(++) M-(--) V-- PS+ PE Y+ PGP+ t-- 5++ X R*(+) tvi(+) b+++(++) DI+() D+(++)
G++ e>+++ h+ !r !z+
------END GEEK CODE BLOCK------
Reply to: