apt-0.5.15lorg3.1-rc2

[Ralf Corsepius]

On Tue, 2006-05-16 at 20:06 +0300, Panu Matilainen wrote:
> 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.
Nope, one of my local changes was having reverted your "svn -r 159:160
diff", because I am having doubts on the changes it introduces [1] and
wanted to exclude it to be the cause.

> Have you done "rm -f /var/cache/apt/*.bin" lately?
Yes. The result changes a bit between apt-get runs (may-be due to
repositories changing) over time, but basically remains similarly
broken.

[Besides this, I am using nfs-shared per-distro cache
dirs: /var/cache/apt/fedora/<version>.]

> > > ...
> > > 
> > > 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?

I can deterministically reproduce it on one machine:
# rm -f /var/cache/apt/fedora/5/*.bin
# apt-get -d -c /etc/apt.fc5/apt.conf dist-upgrade
..
The following packages will be REMOVED:
   apt (1.6.2-3jpp_8fc)
..

On another machine:
...
The following packages will be REMOVED:
   apt (0.5.15lorg3-0.20060516.1642.fc4)
...

The same (rsync'ed) apt-configurations, 
identical (nfs-shared) /var/cache/apt/fedora/5/, 
similar (but not identical) setup.

The only difference had been the machine which complained about apt had
a locally built apt.rpm installed. 

What I don't fully understand about this, is apt's reaction, because my
local fc5 repo had contained an apt.rpm with a lesser version, but with
otherwise correct dependencies (i.e. the installed fc4 rpm carried a
newer NVR than the fc5 version inside of the repo).

> > > * 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.
Well, a "hot" dist-upgrade ends up with ...

E: Failed adding /var/cache/apt/fedora/5/archives/kernel#2.6.16-1.2096%5fFC5_2.6.16-1.2096%5fFC5_i686.rpm to transaction (install)

=> I don't think it's as harmless as it might seem at first glance.

> > 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?
Yes, on 2 different machines.

> 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 :)

# rpm -qa 'kernel*'
kernel-2.6.16-1.2108_FC4
kernel-module-nvidia-2.6.16-1.2108_FC4-1.0.8178-0.lvn.4

> 
> Reminds me, we'll need to force a cache rebuild on the next release
> anyway somehow.
Hmm. Doesn't apt-get "dist-upgrade" already do so?

Ralf

[1] epoch handling is an installation target system's feature. Your
patch uses a build-host's feature. This makes a difference when
dist-upgrading between distributions using different interpretations of
epochs (say RH9 to FC4).