pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The pkgsrc-2006Q1 branch



On Fri, 31 Mar 2006 12:30:27 -0500, Anne Bennett
<anne%porcupine.montreal.qc.ca@localhost> 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



Home | Main Index | Thread Index | Old Index