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.

We don't need to branch for that. All we have to do is be judicious
about which packages we update, and bump "nb" numbers as required (not
after every change, but after any change which would motivate someone
to update the binary package).

Branching won't help unless people take _more_ _care_ maintaining the
branch than they now do for the HEAD, and that's not simply not going
to happen.

> 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.

It's funny you should use "png" as an example. In the past, "png" has
deprecated functions by putting a "break me" in the installed headers,
while still compiling the function in, and without bumping the minor
(the goal being to preserve ABI, but not API). At those times,
recompiling the application packages without fixing their source is
_exactly_ the wrong thing to do. What the user should be doing,
instead, is reinstalling the same binary package. In many cases, it'll
be binary packages that he's already collected, via download or CD.


Frederick