Re: sarge->etch upgrade hits dependency hell
On Fri, Dec 08, 2006 at 06:48:32PM -0200, Gustavo Franco wrote:
> On 12/7/06, hendrik@topoi.pooq.com <hendrik@topoi.pooq.com> wrote:
> >On Thu, Dec 07, 2006 at 03:30:47PM -0500, Sarunas Burdulis wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> hendrik@topoi.pooq.com wrote:
> >> > After failing to reconstitute my etch system (details abundantly
> >> > available on this mailing list a few months ago), I wiped its partition
> >> > and tried to install etch form scratch using installer release
> >candidate
> >> > one, only to find that lilo crashed when it was trying to make the
> >> > system bootable (installation report has been submitted).
> >> >
> >> > So my next attempt was to copy the still-running sarge system I have on
> >> > another partition into my etch partition, and to try to upgrade the
> >copy
> >> > to etch by changing /etc/apt/sources to read 'etch' where the old one
> >> > reads 'sarge', starting aptitude, and upgrading.
> >> >
> >> > My first attempt was to try to upgrade aptitude first. No luck.
> >> > Trying to upgrading aptitude immediately led to hundreds of packages
> >> > that would be deleted. My guess is they were caught in the libc
> >> > transition.
> >> >
> >> > My second attampt was to try 'U' so as to do a general upgrade. Again,
> >> > huge numbers of deleted packages, and a huge number of packages to be
> >> > installed, too. Went ahead with it anyway, after rescuing aptitude
> >> > itself -- it had decided it was appropriate to delete aptitude without
> >> > installing it again. But just typing '+' on aptitude was enough to
> >> > restore it without problem, so I don't know why it decided it was to be
> >> > removed in the first place.
> >> >
> >> > After about three to four hours of downloading, it started the
> >upgrades.
> >> > Several problems immediately. It couldn't upgrade fontconfig or pysol,
> >> > and refused to try further. pysol needed python2.4, don't know why it
> >> > decided to do that first. fontconfig is now unusable, which causes
> >> > troubles elsewhere.
> >> >
> >> > After various attempts to solve the problems, I am left with a huge
> >> > number of packages to be deleted/upgraded/installed, and X that won't
> >> > work, and a list of 18 packages that have problems.
> >> >
> >> > Should I try again tomorrow in the hope that package dependencies will
> >> > sort themselves out? Or should I just give up and try another way of
> >> > installing tomorrow? Can't think of one now, but one will probably
> >come
> >> > to me it I think hard enough.
> >> >
> >> > -- hendrik
> >> >
> >> Sound like what I have seen "as usual" while doing dist upgrades (Debian
> >> and Ubuntu). Several apt-get {update|upgrade|dist-upgrade|-f install}
> >> cycles often are needed. Some packages almost always get "stuck", i.e.
> >> cannot be upgraded or prevent other packages to be upgraded. For those I
> >> do apt-get remove and then install.
> >
> >The hard part is to identify the key packages that are blocking all the
> >rest.
>
> Hi Hendrik,
>
> After all you've a updated (as in testing) aptitude, right? Please do:
> aptitude install desktop gnome-desktop if you're using GNOME,
> otherwise use 'desktop kde-desktop' (xfce-desktop will enter testing
> soon).
Yes, I should have thought of using dpkg. I used aptitude. Aptitude
has has no problems upgrading itself before. I figured out about dpkg
when I was having no luck deleting xfractint (dpkg finally did that).
aptitude would comnplain that the xorg transition required getting rid
of /etc/X11R6/bin and that it couldn't figure out how to do that because
xfractint was on record as needing files in that directory. Telling it
to delete xfractint wasn't good enough. I had to actually get it
deleted before it would stop complaining.
>
> Feedback is appreciated.
At present etch has lost net access. sarge still has it, so I'm
planning to tell etch to use a CD as a package source. I hope the
program that scans CDs and adds then to the /etc/apt/sources.list file
is in working order. Then I'll tell it to install a recent kernel and
maybe udev will stop complaining about the kernel version and I can get
/dev/eth* back.
Ah! wait -- there's hope -- it did manage to install a kernel -- it just
hasn't gotten it onto the boot menu yet. Now there's something easy to
do from the working (as always) sarge system!
-- hendrik
Reply to: