On Thu, 19 Oct 2000, Matthew Orgass wrote:

: > It's maintained by a third party, and we don't have significant local hacks
: > that have no other maintainer, so it is easier to maintain by keeping it in
: > pkgsrc.
: > </VENT>
: 
:   I don't think that this is a good standard of inclusion, though
: hopefully it will not be long before the base system is packageized and
: "what"  becomes separate from "how".

It's a very subjective issue, and as you can see above, this was a rather
directed <VENT>.  Here's the story's summary:

There are some things that a typical modern Unixlike OS usually has as
OS-maintained components, and usually (but not always) because the
components have little "outside" maintenance.  You have the Bourne shell
(and C shell), the usual shell utilities, at least one mail agent, a
compiler/development toolchain, a printing subsystem, IP-based utilities,
and a manpage formatter.

There have been pushes in the directions of both bigger and smaller base
distributions (obviously I'm primarily in the latter group), and usually it
comes down to a case-by-case "need vs. maintenance time" evaluation.  I had
felt that CVS wasn't well evaluated in the maintenance time area.

CVS is an iffy issue.  On one hand, you can access anoncvs with it and do
more complex revision control tasks than RCS is capable; on the other hand,
it's a fairly fast moving target when it comes to getting bug fixes
integrated, so maintenance cost is high.  So does it go into src or pkgsrc?

From most of the discussions like this, the end result is typically:  
Pkg-izing something not in the list two paragraphs ago, that is well
maintained by a third party, is mostly acceptable--*provided* that NetBSD
offers a very simple and easy way to fetch the pkg-ized versions for
installs or upgrades, and that a core set of pkgs (like cvs and lynx) is
always built on all platforms alongside a release.

Since we don't have these two very important prerequisites, it's hard to get
anyone to agree on what should and shouldn't be in src.  My vent was more of
a plea, in far fewer words, "please stop pulling more stuff into basesrc and
work instead on making software granularity easier to live with."

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.