On Thu, 29 May 2003 15:06:55 -0400
stan <[EMAIL PROTECTED]> wrote:
>
> I can't speak for unstable, but at the moment, testing is quite a mess
> and has been for about 2 weeks. You can't use dselect with essentially
> destroying your system, and hand apt-get upgrades give 100+ packages not
> upgraded.
>
> After over a year of almost no problems running testing, on half a dozen
> machines, this started about 2 weeks ago, and continues to get worse
> every day.
>
> I've sent a mail to this list but got no clues as to when this was going
> to be resolved.
>
> So, at the moment, I'm not even certain you _can_ install testing :-(
I'm running sarge; and while I *am* seeing what you're talking about, I'm
not finding it this bad at all. Maybe it's the differences in the set of
packages we have installed, but I'm able to make this be a lot more
liveable by just doing some manual intervention.
First off (and I know you know this, but it's worth restating, especially
for anyone coming in late who didn't see your earlier thread) . . .
"apt-get upgrade" will not remove packages, and will not install packages
that previously were not on your system. This matters because sometimes
the functional organization of packages change. As an example, consider
"libfoo" being replaced by "libfoo-partA" and "libfoo-partB". When
package "bar" gets replaced in testing by a new version that depends upon
the new library structure, and you have "bar" installed, apt-get upgrade
will hold that package back, because to complete the upgrade it'd need to
also replace "libfoo" with the two new libraries, and "upgrade" can't
remove old packages or install new ones.
"apt-get dist-upgrade" is supposed to be able to handle this sort of thing.
But sometimes there are things it can't resolve without doing something
you don't want. For instance, suppose a new version of perl comes down
into testing. And suppose there's a package (like "apt-file") that
depends on the older version, and conflicts with the newer one. If you
want to upgrade to the new version of perl in testing, then apt-file will
be broken, and so "dist-upgrade" will try to remove it.
Right now, both of these sorts of situations have developed recently in
testing: there are package upgrades available which include changes in
the package dependencies, and "apt-get upgrade" can't handle that. But
"apt-get dist-upgrade" won't help you either, because there are also
package upgrades available which, upon upgrading, will break the
dependencies for some other installed package, suggesting its removal.
This has happened before, and doubtless will happen again.
Again, sorry if you know all of that stuff; but just in case not, and
just in case anyone else is bothering to read this.
So what do you do about this? Well, with regard to the upgradeable
packages whose upgrading will break others' dependencies, there isn't
much you can do if you want to strictly track testing. You can try
fetching out of unstable the packages whose dependencies would be
broken, but sometimes an updated version hasn't made it there yet
either. Personally, I deal with such packages mainly by just waiting.
There's never been a situation where anyone's life depended on it,
so I don't mind waiting a few weeks or even months for it to sort
out.
But that still leaves the packages that *are* upgradable, but can't
be handled by "apt-get upgrade" because of changes in their
dependency structure. These are probably easiest handled using
aptitude or something like that, but I'm still an aptitude-newbie.
I typically deal with them manually, using "apt-get install."
First, I do an "apt-get upgrade" and see the list of packages held
back. Then, I do an "apt-get -s install" of that same package list
and look at the messages it returns. Sometimes this will come back
with one of those error messages that looks like "error: can't
install package foo, requires bar 2.4 but version 2.3 is to be
installed." I trim that package off my list and "apt-get install"
again. I repeat this as much as necessary until it successfully
runs (or would have run, given that I'm using "-s"). At that point,
it gives me a list of packages it would like to remove, and new
packages to install, to complete my command. Then I play with
the list some more until I get it down to a subset that doesn't
require anything to be removed. Sometimes I use aptitude to check
the version dependencies and conflicts for individual packages, to
determine why a package is being held back. Sometimes I pick my
way through the held packages list one-by-one, finding packages
I can safely install and installing that way.
Right now, I've got 39 packages held back. Nearly all of those
are related to the perl upgrade in testing in some way: they're
perl packages, or they're packages that depend on those newer
versions of those perl packages. Without manual intervention, I
know that number would be greater than a hundred; but the others
were packages that could be installed through "install" without
removing anything, and so that's what I did.
Is this a pain in the ass? Sure, of course; but that's what we get
for running sarge. I think of testing as kind of like a box in
which the different elements of the new release are being placed,
continually being replaced by new versions as they become available
(according to the rules for stuff moving from unstable to testing).
At any given point, up until the time of release, it's possible for
some of the stuff in that box to not get along well with other stuff
in that box. This sort of thing happens from time to time, especially
when it involves upgrades to stuff like perl or python (which also
happened recently). There's a certain extent you can minimize it
manually, as per above; otherwise, you just gotta tough it out. If
it gets just too annoying, consider running stable or unstable,
both of which are better choices from a security standpoint.
Hope this is helpful; sorry for being long-winded.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
