apt-0.5.15lorg3.1-rc2

[Panu Matilainen]

On Tue, 2006-05-16 at 18:38 +0200, Ralf Corsepius wrote:
> On Tue, 2006-05-16 at 18:32 +0200, Ralf Corsepius wrote:
> > On Tue, 2006-05-16 at 18:21 +0300, Panu Matilainen wrote:
> > > Ok, this is now with the filelists fix, no other changes from rc1.
> > > Tested to survive fc4 -> fc5 upgrade calculation which is just about as
> > > acid as a depsolver test gets :) 
> > > 
> > > http://apt-rpm.org/testing/apt-0.5.15lorg3.1-rc2.tar.bz2
> > > 
> > > Please try to give it a spin,
> > 
> > Works MUCH better ...
> > 
> > >  I'm planning on putting final lorg3.1 out
> > > this weekend unless something dramatic turns up.
> > 
> > Another observation[1]:
> > 
> > During a dist-upgrade from FC4->FC5 on a Fedora 4 system:
> > ...
> > The following packages will be REMOVED:
> >    freeglut-devel (0:1.6.2-3jpp_8fc)
                      ^^^

That looks suspicious, you shouldn't see those *anywhere* anymore unless
you're using rpm older than 4.2.1 which certainly isn't the case on FC4.
Have you done "rm -f /var/cache/apt/*.bin" lately?

> > ...
> > 
> > This is wrong twice:
> > * freeglut-devel is available for FC5, so there should not be any need
> > to remove it.

Yup, that's a bit strange. I guess it *could* be related to the
epoch-stuff somehow, can you check if it still happens after a full
cache rebuild?

> > * The version number being issued doesn't correspond to freeglut-devel.
> > It seems to be FC4's "ant"'s version.

That's probably the ages old bug in the version viewing code which gets
utterly confused when package replaces occur. Really should clean that
up one of these days, but that's purely cosmetical. Assuming this indeed
is that particular issue and not something else.

> And yet another observation from the same "apt-get dist-upgrade" run
> ...
> The following NEW packages will be installed:
> ...
>    kernel#2.6.16-1.2096_FC5 (2.6.16-1.2096_FC5)
>    kernel#2.6.16-1.2111_FC5 (2.6.16-1.2111_FC5)
> ...

Hum.. again, can you check if this happens after a full cache rebuild?
Or do you have kernel modules installed that could affect this somehow
(not that I can see how it would end up with that result anyhow :) 

Reminds me, we'll need to force a cache rebuild on the next release
anyway somehow.

> 
> > Ralf
> > 
> > [1] Using svn 161 with a couple of local patches applied - I doubt these
> > local patches are responsible, but would not want to exclude the
> > possibility of the disturbing something. 

That's always a possibility of course, libapt-pkg being the brittle ...
that it is...

	- Panu -