How I make apt-pinning work (in reference to some myths about apt pinning)
Sorry I'm in on the discussion so late, but thought I would let people
know what I do.
I run debian woody (mostly as you'll see) these days because unstable
has been just that. I used to run unstable all the time, but anyway...
I use woody with packages that I build from unstable. I simply:
apt-get source blah
dch -i
dpkg-buildpackage -rfakeroot
As stated in previous posts, this only works out of the box for simple
packages. However, if you want to put a little work into it, you can
get everything from evolution 1.2.1 and mozilla 1.2 to gnucash 1.7.8
compiled from unstable to build on woody. Basically, I read the README
file of the original tarball for what the minimum build dependencies
are. If these minimum dependencies are in woody, I then change
debian/control (and sometimes debian/control.in) to reflect the woody
packages. This way I don't end up with a massive manual upgrade of
packages. If I don't have the minimum version of the package, I just
get it from unstable. There are surprisingly few additional packages
that need to be updated to sid (mozilla is a prime example). Sometimes
I also need to modify debian/rules to disable on option or to not build
an optional package (like in the case of gnucash, I disabled hbci and
just deleted gnucash-hbci from debian/control).
I then create my own apt repository, and let my users apt-get these
packages, so we have the stability of woody (and the same libc, pam,
etc), but the select few new killer apps from unstable. I do see the
potential for problems if the package maintainer's version of an app
requires a higher version of a library than the README file states-- but
then you can always read the debian/changelog and upgrade what is
needed.
>From a security standpoint, I just subscribe to the debian security
mailing list and watch for updated versions in sid. I do use apt
pinning to pin my new packages just to be sure there are no upgrades--
but user's sources.list only has woody lines in them anyway. I document
the work I did to get them to compile on woody in the first place, so
doing it again isn't too bad. In fact, once you do it once or twice at
all, it becomes easy to build these newer packages on woody.
Of course, there will be the occasional package that it is just not
worth it to build on woody, and some that need debhelper updates and all
kinds of other stuff. In general though, I am very happy with this
solution, and am eager to hear other people's opinions.
Jamie Strandboge
--
Email: jstrand1@rochester.rr.com
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
Reply to: