apt-0.5.15lorg3.1-rc2

Panu Matilainen pmatilai at laiskiainen.org
Wed May 17 02:02:15 PDT 2006


On Wed, 17 May 2006, Ralf Corsepius wrote:

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

Ok, that explains the epoch there then. Note that without the that 
epoch-patch, apt will be somewhat confused about different package 
(they show as different versions in 'apt-cache showpkg <pkg>' output) and 
can lead to some other mishaps.

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

Ok, just wanted to be sure, but these aren't related to that afterall.

>>>> 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 version stuff is simply broken, just ignore. It'll only show correct 
versions if no packages get replaced IIRC, anything else will have bogus 
versions here and there depending on what exactly gets replaced.

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

Apt will never downgrade on dist-upgrade unless pinning is used, so in 
this case it can only self-destruct.

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

This is a different issue altogether, see 
http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/2006-May/000155.html
The failure to add to transaction is caused by two versions of the same 
package being in the same transaction, something rpm doesn't allow/like: 
try installing two kernels with 'rpm -ivh kernel*rpm' and it'll complain 
about "kernel blaa already added, replacing with...". Yes, it's a 
situtation apt should handle more cleanly but mostly this is just bad 
interaction with upgradevirt.lua and conflicting packages and is not a new 
issue AFAICT.

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

Not automatically, only if the cache is considered "invalid" based on 
various calculations.

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

Sure, but what can you do? On such an upgrade-scenario, the apt used to do 
the upgrade is linked to rpm 4.2.0. Even if you made the epoch-hiding 
behavior run-time switchable it'd still be using the rpm 4.2.0 API with 
it's broken epoch rules and would just fail in spectacular ways because 
the new packageset is built assuming different epoch-rules.

 	- Panu -



More information about the Apt-Rpm mailing list