Pinning to testing

From: Kjetil Kjernsmo (kjetil_at_kjernsmo.net)
Date: 12/30/03

  • Next message: Alvin Oga: "Re: Using RAID chipsets in the motherboard. - yup" 
    To: debian-user@lists.debian.org
Date: Tue, 30 Dec 2003 23:37:40 +0100

    Hi all!

    I was wondering if anybody could explain pinning to me... I know several
    sources, yes, but just one more time... Please...?

    OK, here's the problem:

    I've been tracking unstable on my workstation for a few months now, and
    I'm pretty happy with it, it's up-to-date now and I have the stuff I
    need. It's time to stabilize a bit (after kdm has been uploaded). So,
    from now on, I'd like to be tracking sarge, but certain packages should
    still be installed from unstable if I ask for it explicitly.

    Take for example python2.3. I've had that on hold for some time now, so
    what I have installed is 2.3.2.91-1. Unstable has 2.3.3-1, whereas
    sarge has 2.3.2-2. The idea is that if I go apt-get upgrade, I would
    get sarge's version, but if sarge's version is older than the one I
    currently have, it would just leave it and wait for a higher version to
    become available. I don't want to downgrade anything.

    Pinning is for this purpose, so I tried to create a preferences file.
    Initially, it started like this

    Package: *
    Pin: release a=unstable
    Pin-Priority: 302

    Package: *
    Pin: release a=testing
    Pin-Priority: 550

    After unholding python2.3, and go apt-get upgrade, it started to pull
    2.3.3-1 from unstable. Hm. Back to reading. I've read
    http://www.argon.org/~roderick/apt-pinning.html and the APT HOWTO:
    http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-pin
    The latter says:
    | Priorities 0 to 100 denote packages that are not installed and that
    | have no available versions.

    Hm, this doesn't really make much sense to me in the context of
    apt-pinning: Why would one set the pin to <100? Just to say that it
    isn't installed...? And that it won't be installed even if I ask for it
    explicitly? That got me really confused. But then:

    | Priority 100 is the priority assigned to an installed package - for
    | the installed version of a package to be replaced by a different
    | version, the replacement must have a priority greater than 100.

    OK, so in spite of my confusion above, it seems like if I set the
    priority to below 100 for unstable, it will not replace allready
    installed version, because the priority for unstable will be less than
    the priority of allready installed packages. Sarge, OTOH will have
    priority of 550, so it will be installed. That's what I want.

    So, now my preferences look like:
    Package: *
    Pin: release a=unstable
    Pin-Priority: 99

    Package: *
    Pin: release a=testing
    Pin-Priority: 550

    apt-get upgrade, however, doesn't agree with my reasoning... It starts
    pulling python2.3 2.3.3-1 from unstable archives...

    I've also tried reordering the entries, run apt-get update, etc. They
    don't make any difference...

    One concern I get out if this as well, it sounds like if I keep a pin
    <100 for unstable, it is not going to be installed even if I ask for
    it? That's not what I set out to achieve...

    So, if anybody would care to explain this just another time, I would be
    happy! :-)

    A Very Happy New Year to everyone!

    Best,

    Kjetil 

    -- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net  webmaster@skepsis.no  editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/        OpenPGP KeyID: 6A6A0BBC
-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Alvin Oga: "Re: Using RAID chipsets in the motherboard. - yup"

    Relevant Pages