Subject: Re: The pkgsrc-2006Q1 branch
To: Anne Bennett <anne@porcupine.montreal.qc.ca>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: pkgsrc-users
Date: 03/31/2006 12:58:17
On Fri, 31 Mar 2006 12:30:27 -0500, Anne Bennett
<anne@porcupine.montreal.qc.ca> wrote:
>
> I have installed about 300 packages from source, based on 2005Q4
> (and occasional updates to 2005Q4 since last December). What does
> it mean to me in practice that 2005Q4 has been deprecated? Is it
> expected that I would re-install all of my software every few
> months? If not, how long will security patches continue to be made
> on 2005Q4? If I want an update to a particular package as found
> in a more recent pkgsrc branch, is there a way that this update
> can coexist peacefully with the rest of my installed software,
> short of giving it a whole separate directory hierarchy?
>
There are two different issues here: bug fixes and how they're dealt
with in pkgsrc.
Pkgsrc usually does not contain security bug fixes, though there are
exceptions. Remember that pkgsrc is mostly a set of pointers to other
people's code. If package net/foo-1.2.3 has a security problem, the
usual course is for the maintainer of foo to create net/foo-1.2.4 that
fixes it. At some point, the maintainer of the foo package would
update it to point to foo-1.2.4 instead. (I've oversimplified here,
but it's basically correct.)
The problem is that dependencies change. foo-1.2.4 might require
devel/bar-5.6.8 instead of bar-5.6.7, so you'd have to upgrade (or
delete) bar in order to recompile foo. But bar is relied upon by a
dozen other packages, including some huge ones like meta-pkgs/kdefgh.
all of which will need to deleted and recompiled.
There are no great solutions here. You can periodically refresh your
entire /usr/pkg tree; if you're lucky, you can do the rebuilds via
pkg_comp in a chrooted partition. Or you can use pkg_chk to rebuild
everything, or lintpkgsrc+pkgdepgraph to figure out what's out of
date. About 1 time in 3 that I try this, I find that *something* won't
rebuild.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb