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.

-Dan