Re: APT::Default-Release accepts code-names? (long)
On Sat, Jan 13, 2007 at 12:19:08PM +0200, Andrei Popescu wrote:
> Greg Folkert: sorry for the CC, but you kept ignoring my other messages
> about this.
>
> Dear all,
>
> In the thread 'smooth upgrades' that was still running a few days ago
> there was the question of release names vs. code-names in the
> Default-Release option. The docs
> http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version
> and 'man apt_preferences' ('man apt.conf' doesn't mention it at all)
> only talk about release, but don't exclude code-names specifically.
>
> I thought I should do an experiment:
>
> Let's suppose an etch system, but the user needs (wants) some packages
> from unstable or even experimental and no apt.conf
>
> think:~# cat /etc/apt/sources.list
> deb http://ftp.ro.debian.org/debian/ etch main
>
> deb http://ftp.ro.debian.org/debian/ sid main
>
> deb http://ftp.ro.debian.org/debian/ experimental main
>
> think:~# cat /etc/apt/apt.conf
> cat: /etc/apt/apt.conf: No such file or directory
> think:~# apt-cache policy
> Package files:
> 100 /var/lib/dpkg/status
> release a=now
> 1 http://ftp.ro.debian.org experimental/main Packages
> release o=Debian,a=experimental,l=Debian,c=main
> origin ftp.ro.debian.org
> 500 http://ftp.ro.debian.org sid/main Packages
> release o=Debian,a=unstable,l=Debian,c=main
> origin ftp.ro.debian.org
> 500 http://ftp.ro.debian.org etch/main Packages
> release o=Debian,a=testing,l=Debian,c=main
> origin ftp.ro.debian.org
> Pinned packages:
>
> etch and sid have equal priority. A dist-upgrade will upgrade the
> system to sid, but we want to keep it running etch. It was suggested
> that if the sources.list uses code-names, than Default-Release should
> work with code-names as well.
>
> think:~# echo 'APT::Default-Release "etch";' > /etc/apt/apt.conf
> think:~# apt-cache policy
> Package files:
> 100 /var/lib/dpkg/status
> release a=now
> 1 http://ftp.ro.debian.org experimental/main Packages
> release o=Debian,a=experimental,l=Debian,c=main
> origin ftp.ro.debian.org
> 500 http://ftp.ro.debian.org sid/main Packages
> release o=Debian,a=unstable,l=Debian,c=main
> origin ftp.ro.debian.org
> 500 http://ftp.ro.debian.org etch/main Packages
> release o=Debian,a=testing,l=Debian,c=main
> origin ftp.ro.debian.org
> Pinned packages:
>
> No effect whatsoever! Let's change 'etch' to 'testing'.
>
> think:~# sed -i -e s/etch/testing/ /etc/apt/apt.conf
> think:~# apt-cache policy
> Package files:
> 100 /var/lib/dpkg/status
> release a=now
> 1 http://ftp.ro.debian.org experimental/main Packages
> release o=Debian,a=experimental,l=Debian,c=main
> origin ftp.ro.debian.org
> 500 http://ftp.ro.debian.org sid/main Packages
> release o=Debian,a=unstable,l=Debian,c=main
> origin ftp.ro.debian.org
> 990 http://ftp.ro.debian.org etch/main Packages
> release o=Debian,a=testing,l=Debian,c=main
> origin ftp.ro.debian.org
> Pinned packages:
>
> Now 'etch' has priority 990 vs 500 of sid. This will keep the system
> running *unstable* (when etch is released apt will want to upgrade to
> next testing).
>
> If you don't spot any mistakes in my logic I would like to file a bug
> report against the docs to avoid any future confusion.
>
I looked into this situation over a year ago. I might even have posted
a comment on it to this list. What I found was that some parts of the
package system use the code names in the data files and other parts
use release names. There is internal inconsistency within the database
design that would be very time consuming to fix. I, personally, think
that the developers have much better things to do than fix this.
OTOH, people who are involved in maintaining user documentation should
avoid statements that would lead a new user to believe that the two
types of names (release and code) are absolutely equivalent. They are
not equivalent if you attempt to use the priority pinning features, and
maybe other features that I haven't look at. (But how many newbies do
use priority pinning? Maybe this, also can be displaced by higher
priority tasks.)
JMTC
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: