Re: apt-rpm and vesion precedence

On Thu, 11 May 2006, Yannick Patois wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I would like to thanks everybody for their useful answers.
> Unfortunately, as often the bug is between the chair and the keyboard:
> there was some pinning in the preference, installed by default, so I
> didn't thought to it :-(

Right. Well, I'm mostly just happy it *was* pinning and not some strange=20
versioning bug in apt :)

> Panu Matilainen a =E9crit :
>> On Thu, 11 May 2006, Yannick Patois wrote:
>>> I think that the order of the pkgs above is by decrescent upgrade, and
>>> it seems fine, for now: 1:30X-10.ires is bigger than 1:30X-10.cern
>>> because 'i'>'c', right?
>>
>> Version comparisons involving strings are depend to some extent on the
>> used rpm versions, but yes 1:30X-10.ires should be considered as
>> newer than 1:30X-10.cern by rpm 4.2.x
>>>
>>> But when I try to upgrade:
>>> # apt-get upgrade
>>> Reading Package Lists... Done
>>> Building Dependency Tree... Done
>>> The following packages will be upgraded
>>>   apt-sourceslist (303-8.ires1 =3D> 30X-10.cern)
>>>
>>> Why is the 30X-10.cern selected first?
>> In apt other things can affect the package selections, namely pinning in
>> various forms. What does 'apt-cache policy apt-sourceslist' output?
>
> There is some pinning, have a look:
>
> # apt-cache policy apt-sourceslist
> apt-sourceslist:
>  Installed: 303-8.ires1
>  Candidate: 1:30X-10.cern
>  Version Table:
>     1:30X-10.ires 0
>        500 http://sbglinux.in2p3.fr ires/slc30X/i386/ires pkglist
>     1:30X-10.cern 0
>        980 http://sbglinux.in2p3.fr mirror/cern/slc30X/i386/apt/updates
> pkglist
> *** 303-8.ires1 0
>        500 http://sbglinux.in2p3.fr ires/slc30X/i386/ires pkglist
>        100 RPM Database
>     303-8.ires 0
>        500 http://sbglinux.in2p3.fr ires/slc30X/i386/ires pkglist
>     303-8.cern 0
>        980 http://sbglinux.in2p3.fr mirror/cern/slc30X/i386/apt/os pkglis=
t
>        980 http://sbglinux.in2p3.fr mirror/cern/slc30X/i386/apt/updates
> pkglist
>     303-7.cern 0
>        980 http://sbglinux.in2p3.fr mirror/cern/slc30X/i386/apt/updates
> pkglist
>     30X-9.cern 0
>        980 http://sbglinux.in2p3.fr mirror/cern/slc30X/i386/apt/updates
> pkglist
>
> That's pretty annoying :-(
>
> I guess that default pinning is 500, and that even a more recent version
> wont beat a 980 pin :-(
> Is there a way to alter the package so that it would take precedence?

Pin priority overrides anything else, there's no way around that with just=
=20
package versions. What you *could* try is obsoleting the old package=20
(you'd have to rename the package for this) BUT I don't think that'd work=
=20
either, or if it did it'd be a bug to allow lower priority package to=20
obsolete a package with higher priority.

> My problem is that I have a few tens of machines, using automatic update
> from a default source, and I added my own to override a few pkgs. I
> didn't saw that the original source sneakily added this pinning, thus
> never selecting my packages. Can I do something without having to log
> into each machine to tune this pining?

I guess your best option would be to try to make your repository look like=
=20
one of the cern mirrors so the same 980 pin would take effect for your=20
repositories. Whether it's possible depends a bit on how exactly the=20
pinning has been set but generally it should be possible. So the only=20
change would take place on the repository level. There is one=20
possible caveat: it might require full cache rebuild to get apt to notice=
=20
the changed repository release-entries and that can't be automatically=20
triggered. Back to square one if that's the case.

If everything else fails, just put your package into the cern updates=20
mirror repository (and update the repository metadata locally) for a while=
=20
so it gets updated. It wont be a "pure mirror" in that case of course=20
anymore but it'll get the job done.

 =09- Panu -