Subject: Re: Binary package sets
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-pkg
Date: 04/24/2001 18:26:11
    Date:        Tue, 24 Apr 2001 12:28:08 +0200
    From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
    Message-ID:  <20010424122808.A23318@antioche.lip6.fr>

  | But with a branch, you can have code different between branch and trunk.

I understand why people would like to branck pkgsrc, and it sure would be
truly convenient if it would work, and not cause too many headaches, but
I doubt that it is really feasible.

It isn't the added load on the ftp servers (space load if nothing else),
that is the problem, or any particular difficulties managing the cvs stuff.

What makes it so hard for pkgsrc is that pkgsrc refers to other people's
code, and there's no way anyone can expect them to know that we branched
pkgsrc on July 13 1994 and therefore whtever version of their code they
were distributing at that date needs to be retained forever.

And without that, there's no way to maintain a stable branch as of the
date that NetBSD-1.4 forked, or anything else, the branch would need to
continually be updated forever - in fact, it would really just duplicate
the head of the tree anyway (about the only difference is that it wouldn't
get new packages added to it perhaps, which would make it less attractive,
not more).

Certainly, simply being able to update the 1.4 binary package collection
after someone discovers a security hole in wu-ftpd isn't going to work,
as that's likely to depend upon a version of readline (or something) which
is no longer available, and updating that will then require updating
everything else which depends upon it ... just like as if it is done via
the current pkgsrc.

kre

ps: I guess the other alternative would be for all the distfiles to be
maintained forever by NetBSD .. and blow away all the ones where
redistribution isn't permitted, but somehow, that doesn't sound attractive
either.