Bug#404525: upgrade-reports: sarge->etch upgrade
On Sun, Jan 14, 2007 at 04:26:55PM +0100, Kurt Roeckx wrote:
> > I think we're stuck with having to manually upgrade initrd-tools, the
> > conflicts from glibc isn't really something we can remove.
> So a aptitude dist-upgrade now returns:
> The following packages have unmet dependencies:
> xlibmesa-gl: Depends: xfree86-common but it is not installable
> Conflicts: libgl1 which is a virtual package.
> xlibmesa-glu: Depends: xfree86-common but it is not installable
> Conflicts: libglu1 which is a virtual package.
> libglu1-mesa: Conflicts: libglu1 which is a virtual package.
> xlibs-data: Depends: xbitmaps but it is not installable
> Depends: xcursor-themes but it is not installable
> libxft1: Depends: xfree86-common but it is not installable
> libfam0c102: Conflicts: libfam0 but 2.7.0-12 is to be installed.
> libgl1-mesa-glx: Conflicts: libgl1 which is a virtual package.
.... oh.
Well, crap. Sure, the sarge version of libfam0c102 also has an unversioned
Conflicts: libfam0, and we can't change that after the fact.
In theory we might fix this by restoring libfam0c102 as the real library
package, and getting rid of libfam0, but I'm not sure that's practical.
I guess the only other option would just be to document this in the release
notes as one of the packages requiring special-casing on upgrade.
Your thoughts?
> aptitude install initrd-tools returns:
> The following NEW packages will be installed:
> libdevmapper1.02 libsepol1 tzdata
> The following packages will be upgraded:
> initrd-tools libc6 libc6-dev libselinux1
> 4 packages upgraded, 3 newly installed, 0 to remove and 697 not upgraded.
> And aptitude install libfam0:
> The following NEW packages will be installed:
> gcc-4.1-base libfam0 libstdc++6 tzdata
> The following packages will be REMOVED:
> initrd-tools kernel-image-2.6.8-3-386
> The following packages will be upgraded:
> libc6 libc6-dev libfam0c102 libgcc1
> 4 packages upgraded, 4 newly installed, 2 to remove and 696 not upgraded.
> (apt-get dist-upgrade still seems to work.)
That certainly suggests it's feasible to treat this as a documentation
issue, anyway.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: