Re: Questions about package pinning

On Fri, 2004-07-30 at 16:23, Andre Costa wrote:
> Hi Panu,
> 
> On Fri, 30 Jul 2004 16:06:00 +0300
> Panu Matilainen <[email protected]> wrote:
> 
> [...]
> > > So, I put this on /etc/apt/preferences based on a couple of
> > > references I found with Google:
> > > 
> > > Package: cdrecord
> > > Pin: release c=freshrpms
> > > Pin-Priority: 1001
> > > 
> > > And it seems to be working:
> > > 
> > > apt-cache policy cdrecord
> > > cdrecord:
> > >   Installed: 8:2.01-0.a19.2
> > >   Candidate: (none)
> > >   Package Pin: (not found)
> > >   Version Table:
> > >      8:2.01-0.fdr.5.a27.1 1001
> > >         500 ftp://apt.kde-redhat.org fedora/1/stable pkglist
> > >  *** 8:2.01-0.a19.2 1001
> > >         500 http://ayo.freshrpms.net fedora/linux/1/i386/core
> > >         pkglist 100 RPM Database
> > > 
> > > (although I didn't understand why the "(not found)" for "Package
> > > Pin:"...)
> > 
> > That's because there's no version of cdrecord in "freshrpms"
> > component. You'll want to use
> > 
> > Package: cdrecord
> > Pin: release c=core
> > Pin-Priority: 1001
> 
> Mmmh... ok, makes sense, and it did fix the "(not found)" issue. I
> didn't go that way because it felt to me like there could be many "core"
> components on different repos -- as well as "stable" (for kde-redhat
> above). I guess I got it all wrong.

Not all wrong, just slightly :) The problem is that unless the release.*
files are correctly set up, there's nothing you can do to differentiate
two "core" components from different repositories. Complaining to
repository maintainer is the best thing you can do in that case, see
below...

> 
> > > The thing is: I tried to use:
> > > 
> > > Package: cdrecord
> > > Pin: release c=kde-redhat
> > > Pin-Priority: 0
> > > 
> > > And it didn't work -- apt was trying to upgrade cdrecord to latest
> > > from kde-redhat. My guess is that "c=kde-redhat" is wrong. Or should
> > > I have used Pin-Prioiry = -1?
> > 
> > You'll want negative pin BUT negative per-package pins don't work
> > quite as expected. It might work in the above case but at least if you
> > try to prevent a specific version of a package from installing it
> > doesn't work. I've a patch for the version-case at
> > http://laiskiainen.org/apt/patches/
> 
> Cool. I hope it makes its way into mainstream apt.

Last I talked to Gustavo he had some reservations about it so haven't
committed it yet until I talk to him again (he seems to be on vacation
currently)

>  Still, in the case
> above, why did priority = 0 not work? Or it would work _if_ I also had
> the (fixed) entry for freshrpms above (which seems redundant to me)?

Because there's no "kde-redhat" component? (it's called "stable" and
here we go again with these overlapping component names...)

> 
> > > So, any good reference about apt pinning will be most welcome --
> > > specifically, I'd like to know to specify a, c, o, l, v for a
> > > specific package/repository?
> > 
> > "apt-cache policy" is the best way to see what the various parameters
> > are for a given repository. In many cases the repository maintainer
> > hasn't bothered to enter any meaningful values for most of the entries
> > so 'c' is generally the only reliable parameter (because it's
> > automatically generated)
> 
> Got it. Can we try an "interactive" lesson? ;) Considering the following
> real-case output:
> 
> apt-cache policy cdrecord
> cdrecord:
>   Installed: 8:2.01-0.a19.2
>   Candidate: 8:2.01-0.a19.2
>   Package Pin: 8:2.01-0.a19.2
>   Version Table:
>      8:2.01-0.fdr.5.a27.1 1001
>         500 ftp://apt.kde-redhat.org fedora/1/stable pkglist
>  *** 8:2.01-0.a19.2 1001
>         500 http://ayo.freshrpms.net fedora/linux/1/i386/core pkglist
>         100 RPM Database
> 
> what exactly can I infer from that? Only the "core" and "stable"
> components?

You'll want to use 'apt-cache policy' without any packages after it,
then it becomes quite obvious what to put in there:
[pmatilai@chip pmatilai]$ apt-cache policy
Package Files:
 100 RPM Database
 500 http://fedora.quicknet.nl fedora/2/i386/stable pkglist
     release v=2,o=Fedora Extras,a=stable,l=Fedora Extras,c=stable
     origin fedora.quicknet.nl
 500 http://fedora.quicknet.nl fedora/2/i386/updates pkglist
     release v=2,o=Fedora Core,a=stable,l=Fedora Extras,c=updates
     origin fedora.quicknet.nl
 500 http://fedora.quicknet.nl fedora/2/i386/os pkglist
     release v=2,o=Fedora Core,a=stable,l=Fedora Extras,c=os
     origin fedora.quicknet.nl
 500 file: 2/Fedora/os pkglist
     release v=Unknown,o=Unknown,a=Unknown,l=Unknown,c=os

The last one there is a typical example of incomplete repository setup
where you can only hope that the component is different enough from
everything else. Or complain to repository maintainer...

> 
> > > Feel free to point me to some documentation if it is already there.
> > > I browsed the APT HOWTO info at
> > > http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html, but
> > > IMHO it wasn't very complete with regards to these parameters.
> > 
> > Yep, there's not too much documentation about the gory details of
> > pinning :(
> 
> Ok. IMHO it's a pitty, specially considering that, with more and more
> repositories popping up, package pinning usefulness increases
> proportionally.

Indeed....

	- Panu -