On Mon, 23 Apr 2001 mcmahill@mtl.mit.edu 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 --