Subject: Re: Binary package sets
To: Manuel Bouyer <>
From: Alistair Crooks <>
List: tech-pkg
Date: 04/24/2001 11:48:18
On Tue, Apr 24, 2001 at 12:28:08PM +0200, Manuel Bouyer wrote:
> On Tue, Apr 24, 2001 at 09:51:35AM +0100, Alistair Crooks wrote:
> > Your mail made me think for a long time about this.
> > 
> >  From my experience with cvs and other source code control systems, a
> > branch is used to get all versions of files that someone has "tagged"
> > as being part of a congruent whole.  The problem with this is
> > maintenance of the branch, since usually updates to trunk don't affect
> > branch, and updates to the branch don't affect the trunk.  We'd gain
> > the ability to have known good versions of packages managed together,
> > but what I do is use the "checkout at a known time" abilities of cvs
> > to allow me to get a snapshot of all the packages at a particular
> > point in time, that time to be determined by me using cvs logs.
> > 
> > So, if we branched, we would double the maintenance overhead by having
> > to maintain a branch and a head, and gaining little, since (I think)
> > we already have that functionality using cvs. 
> But with a branch, you can have code different between branch and trunk.
> This may be required if we want a 'stable' package line, only updated
> for security fixes (e.g we update a package which depends on different things
> in branch or trunk; or something in mk/* was changed which requires 2 version
> of the Makefile).
> --
> Manuel Bouyer, LIP6, Universite Paris VI. 
> --

Maybe I wasn't very explicit in my previous message:  you have now
added a tree, equal in size to that of the current pkgsrc.  Are you
going to put that up for ftp as well?  Who is going to manage the
stable tree?  Who is going to organise pullups to the branch?  Who is
going to test any pullups that are made to the branch?

We go to considerable trouble at the moment to make sure that any
changes we do are backwards compatible.  Take the COMMENT change, for
example.  It was enough work making that in the trunk.  To do that on
the branch as well, after a suitable time interval in which testing
has taken place, would be cruelty to the poor people who look after
this stuff.  Then we have the distinfo changes.  I don't like to think
how long it took us to do all of them. If you don't intend to update
the branch like that, but rather leave it static, only updating
packages for security fixes, fine, then it's not a problem.  But I am
absolutely positive that someone is going to pop up and say that they
want kde2 on the stable branch, or the version of postfix that lets
you update this or that, or squid or apache etc.

What you are basically proposing is that we start to branch pkgsrc
in the way that basesrc is branched. However, there's a whole release
engineering team standing behind that arrangement, and a whole lot
more people, in general, maintaining that.

Our resources are not exactly overabundant at the moment. Adding
to the workload is, to me, infeasible.

I could be wrong, and it all manages itself, but somehow, I don't
think so.