On Mon, Apr 23, 2001 at 10:55:22AM -0400, mcmahill@mtl.mit.edu wrote:
> On Mon, 23 Apr 2001, David Brownlee wrote:
> > On Sun, 22 Apr 2001, Thor Lancelot Simon wrote:
> > 
> > > [ updating png on 1.5 system with tagged pkgsrc -> rebuild most packages ]
> > >
> > > P.S. I'm not saying that this is an easy problem to solve, but I *am*
> > >      saying that it is ridiculous to pretend that it is not a problem at
> > >      all.  If we supplied a basic set of built binaries that users could
> > >      use to bootstrap a "bulk reinstall" of packages in this kind of
> > >      situation, that would be one thing -- but we don't; people cannot
> > >      bring themselves to stop *changing* the contents of the binary
> > >      package directory numbered for each release, and they *do not* test
> > >      the packages they upload *with the other packages already there*
> > >      instead of *on the system they built the new package on*, so that
> > >      bad dependencies and stealth package mismatches propagate throughout
> > >      the collection.  In other words, users are forced to regularly rebuild
> > >      huge amounts of stuff from source, so it behooves us to keep the source
> > >      as useful as possible on a continual, not an occasional basis.
> > 
> 
> 
> > 	On the binary package front - would it help if we tried to keep
> > 	the binary package uploads to binary packages generated from
> > 	the bulk package builds? We should have enough people and machines
> > 	to make that work.
> 
> 
> Despite the amount of work it creates, I'm beginning to think we should
> branch pkgsrc.  The goal would then be to do a bulk build for the
> releases.  The only "maintainence" we'd do on the branch is security
> updates.  Also the only binary pkgs we'd put in the "released pkgsrc" ftp
> area would be those from the branch.  That way we don't have the problem
> of someone who has 50 pkgs installed and something needs a security fix.
> Then you go do install a fix, but you can't rebuild from pkgsrc because a
> zillion depends have changed.  Also that way 3 months down the road the
> user with 50 pkgs installed, can still go to the ftp site and add 2 more
> pkgs without realizing that, to use Thor's very good example, png has been
> updated and the binary pkgs which are now available want a newer one.
> 
> our current approach makes it very difficult for users of slower systems
> to apply any security fix.
> 
> of course if a pkg like png (or someother highly depended upon pkg) has a
> security hole, it still may require a lot of recompiling.

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. 

I am not saying that branching is a bad thing, and I think we should
make use of it in pkgsrc development - for example, I think that far-
reaching changes may better be done on a branch and then merging onto
the trunk.

Regards,
Alistair