>: there are probably lots of things that meet this description.  all the
>: games, for example.
>
>Depends in part on both (1) how well these are externally maintained, and
>(2) how long these have been historically in NetBSD and *BSD.  See below, as
>well:

how many of them are externally maintained?

>: fwiw, i use rcs all the time, and cvs almost never, hence, i am
>: opposed to the idea of removing rcs from basesrc.  when working in a
>: small group, rcs is fine.  removing both source code revision control
>: systems from basesrc would be bad.
>
>Filtering non-arguments, the prior discussion points against removing rcs
>from basesrc were, in summary:
>
>1. we don't have a pkgized base system;
>2. sysinst is not capable of installing pkgs;
>3. we don't build any particular packages as a release requirement;
>4. rcs has been in-tree forever.
>
>Point #1 actually supports moving rcs, as a pkgized base system partitions
>rcs into its own binary tarball, which (as far as the installer is
>concerned) could come from either basesrc or pkgsrc.  When this is done,
>I'll likely bring up the prospect of moving rcs again, but I'm _not_
>proposing that now.

fair enough.  as long as it's not too far removed from an installed
system.

>Point #4 weighs only on the historic significance (and the lack of CVS in
>the source tree in the past is why I don't think it should have been
>imported in the first place).

aren't there other things in the tree that are also there simply
because they always have been, yet are used by hardly anyone?

>The prior discussions basically resulted in this conclusion:  if we build
>rcs as a release requirement, and sysinst can auto-fetch-and-install it, rcs
>doesn't need to be in basesrc.

sure.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."