I'm on Ubuntu 10.04, and trying to set up a repository using
reprepro. I'd also like the pin everything in that repository to be preferred over anything else, even if packages are older versions. (It will only contain a select set of packages.)
However, I cannot seem to get the pinning to work, and believe it has something to do with the repository side of things, rather than the
apt configuration on the client.
I've taken the following steps to set up my repository
- Installed a web server (my personal choice here is Cherokee),
- Created the directory
Created the file
conf/distributions, like so:
Origin: Shteef Label: Shteef Suite: lucid Version: 10.04 Codename: lucid Architectures: i386 amd64 source Components: main Description: My personal repository
reprepro exportfrom the
Now on any other machine, I can add this (empty) repository over HTTP to my
/etc/apt/sources.list, and run
apt-get update without any errors:
Ign http://archive.lan lucid Release.gpg Ign http://archive.lan/apt/ lucid/main Translation-en_US Get:1 http://archive.lan lucid Release [2,244B] Ign http://archive.lan lucid/main Packages Ign http://archive.lan lucid/main Sources Ign http://archive.lan lucid/main Packages Ign http://archive.lan lucid/main Sources Hit http://archive.lan lucid/main Packages Hit http://archive.lan lucid/main Sources
In my case, now I want to use an old version of Asterisk, namely Asterisk 1.4. I rebuilt the
asterisk-1:22.214.171.124~dfsg-3ubuntu2.1 package from Ubuntu 9.04 (with some small changes to fix dependencies) and uploaded it to my repository.
At this point I can see the new package in
aptitude, but it naturally prefers the newer Asterisk 1.6 currently in the Ubuntu 10.04 repositories. To try and fix that, I have created
/etc/apt/preferences.d/personal like so:
Package: * Pin: release o=Shteef Pin-Priority: 1000
But when I try to install the
asterisk package, it will still prefer the 1.6 version over my own 1.4 version. This is what
apt-cache policy asterisk shows:
asterisk: Installed: (none) Candidate: 1:126.96.36.199-0ubuntu1 Version table: 1:188.8.131.52-0ubuntu1 0 500 http://nl.archive.ubuntu.com/ubuntu/ lucid/universe Packages 1:184.108.40.206~dfsg-3ubuntu2.1shteef1 0 500 http://archive.lan/apt/ lucid/main Packages
Clearly, it is not picking up my pin. In fact, when I run just
apt-cache policy, I get the following:
Package files: 100 /var/lib/dpkg/status release a=now 500 http://archive.lan/apt/ lucid/main Packages origin archive.lan 500 http://security.ubuntu.com/ubuntu/ lucid-security/multiverse Packages release v=10.04,o=Ubuntu,a=lucid-security,n=lucid,l=Ubuntu,c=multiverse origin security.ubuntu.com [...]
Unlike Ubuntu's repository,
apt doesn't seem to pick up a
release-line at all for my own repository. I'm suspecting this is the cause why I can't pin on
release o=Shteef in my preferences file. But I can't find any noticable difference between my repository's
Release files and Ubuntu's that would cause this.
Is there a step I've missed or mistake I've made in setting up my repository?
Thanks to some help by maxb on #ubuntu-server, I was able to find out some more about what's going on.
It looks like
apt downloads package lists into
/var/lib/apt/lists/. There's a subdirectory there called
partial, which the manpage
apt-cache(8) describes as:
Storage area for state information in transit.
But my repository
Release file gets stuck in there, and is never copied to the parent
lists directory. I can get the pinning to work if I do this step manually:
$ mv /var/lib/apt/lists/partial/archive.lan* /var/lib/apt/lists/ $ rm -f /var/cache/apt/*.bin $ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 1000 http://puppet.motto/apt/ lucid/main Packages release v=10.04,o=Motto,a=lucid,n=lucid,l=Motto,c=main origin puppet.motto 500 http://security.ubuntu.com/ubuntu/ lucid-security/multiverse Packages release v=10.04,o=Ubuntu,a=lucid-security,n=lucid,l=Ubuntu,c=multiverse origin security.ubuntu.com [...]
But the manual step is undesirable, of course.
I also noticed that the
Sources file is missing in my repository, but
Sources.gz is generated. Recreating the
Sources file by unzipping
Sources.gz creates a file that matches the size and hashes in the
Release file. But it doesn't appear to fix my problem.