Subject: Re: src/dist is a *bad* idea (was: New IP Filter v3.3.5 is now in
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 12/12/1999 14:10:27
On Sun, 12 Dec 1999, Greg A. Woods wrote:
> If one of the goals of NetBSD is really to make a clean and elegant
> *source* distribution for an operating system then . . .[no /usr/src/dist]
Some of what you're saying makes a lot of sense. I will advance some
counterarguments simply because you haven't mentioned them, but perhaps i
actually agree with you, although only for very small programs. but, it
is still more important to me that (a) we have the latest version, and (b)
tracking the latest version becomes easier so that it can be done more
frequently without taking time away from real development.
o /usr/src/dist _is_ clean
By ``clean'' perhaps we mean something which makes future development,
maintenance, and comprehension easier. In many cases, this is somewhat
reduceable to ``whatever's easiest.'' The package system is a great
example. bsd.pkg.mk does not look ``clean'' but it concentrates the
inevitable dirtyness of packages onto itself, thus making individual
Makefiles cleaner and shorter, solving common problems once, avoiding
In a less dramatic sense, if dist makes the work of developers who work
on dist'ed things easier, maybe it is ``clean.''
o /usr/src/dist makes local patches easier to maintain across imports
I believe we sometimes make changes in CVS to a source file under dist/.
I don't get the sense that we hesitate to do so. If we do, making the
changes under dist/ instead of in a post-import-script copy means
o the changes are easier to send back to the maintainer
o the changes are easier to roll into the next version, when it comes
o dist is easier because it is the most logical build layout for the type
of development we use it for.
The easiness can be taken as a consequence of a layout that symbolizes
the work we do--it divides into separate pieces the Maintenance of
Foreign Code task and the Coercing of Foreign Code into our Build
Process task. These tasks are very different and ought to be
Even if you argue the layout is harder to understand (depending on your
perspective, it might not be), still at least the CVS histories are
much more useful for a project that was done with dist, and CVS's
usefulness is generally highly dependent on directory layout.
o at least for the case of /usr/src/gnu/dist, it's a useful tree in
The GNU toolchain has a standard build layout of its own, and a lot of
GNU tarballs will extract into a piece of this common layout. They are
trying to do the same thing we are--they're just not doing it as well
and aren't finished yet. But, their layout is still well-considered
and is a worthwhile thing to offer users of our source in itself.
and then there's the licensing thing, which i'm not discussing further.
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US