[ On Monday, December 13, 1999 at 00:13:01 (-0400), David Maxwell wrote: ]
> Subject: Re: src/dist is a *bad* idea
>
> My understanding is that CVS deals with that _very_ well. After importing
> a vendor branch, you can checkout a version that has applied all of your
> local changes on top of the vendor's changes - leaving only the
> conflicting diffs to be fixed by hand.

Only if you never, ever, create any other branch but for the vendor
branch itself.

The diagram in the original CVS-II paper suggesting that multiple vendor
branches could be supported was also basically a pipe dream.  It never
really worked and is almost 100% deprecated in the current CVS.

CVS vendor branches are "magic", relying on an otherwise pretty useless
feature of RCS, the effects of which are not dealt with unless CVS is
doing a few explict vendor-branch related tasks (i.e. primarily only
"cvs import" itself).  The plain "ordinary" branches in CVS are also
magic (using reserved revision numbers to mark the fact that they are
"cvs" branches).  The two cannot play together when any degree of normal
CVS functionality is expected.  Indeed many operations on vendor
branched modules have to be dealt with with much more care than with
ordinary modules.  In the mean time CVS is busy handing out lotsa rope!
Note that there are already a plethora of potential traps set in the
NetBSD repository now because of the misguided use of "cvs import" on
sub-modules within the larger main modules (not to mention the mess
being created almost every day with "repository copy" moves).

The only real safe way to handle local patches to "src/dist" thingies
would be to keep them in separate files, just as with pkgsrc patches,
but of course this presents its own unique set of nightmares, on all
sides of the fence.

That's not to mention the fact that subsystems like IP Filter which
spread themselves amongst several modules in the CVS repository cannot
play together (witness the need for manual copying, and thus
duplication, of IP Filter kernel files into src/sys to work around
this).  [Not that IP Filter has the very best user-land/kernel code
sharing design in the first place, w.r.t. a larger system....  :-)]

Obviously CVS can be used in a restricted manner such that the problems
I'm speaking of are not encountered.  However the evidence of past uses
suggest that the NetBSD users are not willing to use CVS in such a
restricted manner.

> Greg, could you give a clear description of the difficulties you
> percieve the approach will cause?

The other problem that I'm really trying to get across is the fact that
the non-integration of code into the tree makes it infinitely harder for
users of the tree to apply their own fixes and to do their own upgrades
of modules for local/private releases.  I've done this several times now
for IP Filter itself, just as it so happens, in both NetBSD and FreeBSD
over several un-coordinated "vendor" releases of both the OS and IP
Filter, and prior to this recent but increasing obfuscation of NetBSD
the FreeBSD upgrades were a nightmare compared to doing the same in
NetBSD.

This is a very real problem and Perry is seemingly blinded by the fact
that he's only seen the simple and easy initial few cases -- i.e. he
obviously doesn't have the real-world experience I'm trying to share
which I'm saying shows he's wrong, hands down.  Perhaps the magnitude of
these problems are only manifest to someone who's played on all sides of
this fence... I don't know -- I just know that I've grown, i.e. learned
from experience, to really and totally detest the src/dist scheme and
the use of vpath makefiles for building such products.

The *2netbsd scripts are the correct and most ideal solution to the
messy problem of integrating code still being primarily maintained by
third parties.  They allow the sharing of knowledge necessary to do the
integration, and they force the developer doing the integration to gain
enough understanding about what's on both sides of the fence so that the
integration is (usually -- but not always, witness early attempts at TCP
Wrappers in NetBSD) done right.  The result of a tightly integrated
source tree is something that is more managable, more robust, more
elegant, and more understandable as a whole, especially in terms of the
system build tools, but of course in other more general aspects as well.

The CVS problems I discuss above are are really not of my direct concern
(though I of course do worry that they'll affect the overall quality of
the product as they become more manifest and demand more effort on the
part of the direct developers to manage).  I only use the output of the
NetBSD repository and I don't ever expect to have to actually use it
directly (and indeed I'm not sure what I'd do if I was invited to become
a direct developer!  ;-).

(Yes the percieved necessities of segregating licensed code, and the
very real necessities in the USA of segregating crypto code, are warts
on the system, but those we can live with for now.  If we (i.e. source
tree users) didn't want to live with them we'd be off to use OpenBSD in
a moment!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>