Subject: Re: Binary package sets
To: None <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 04/23/2001 18:50:12
On Mon, 23 Apr 2001 email@example.com wrote:
> 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.
In an ideal world I'd like to see us with two sets of pkgsrc
binaries for each architecture+release.
- 'branched' set, with minimal pullups for security issues.
- 'current' set, only updated with the output of a bulk build
(and possibly non built binary packages removed).
Each set will be internally consistent with respect to DEPENDS -
installing the latest png from the current set might involve
updating many other packages, but you should _always_ be able to
do it exclusively wth binary packages.
In the real world, the 'current' set is a much easier goal from
where we are now.
David/absolute -- www.netbsd.org: No hype required --