[BACK]Return to README CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / othersrc

File: [cvs.NetBSD.org] / othersrc / README (download)

Revision 1.1, Sat Sep 4 17:28:23 1999 UTC (15 years, 3 months ago) by perry
Branch: MAIN
CVS Tags: HEAD

initial commit of file explaining what othersrc is for

#	$NetBSD: README,v 1.1 1999/09/04 17:28:23 perry Exp $

	       Information on the "othersrc" Collection

The "othersrc" collection consists of programs that are either "not
ready for the main tree" or "never going to be ready for the main
tree" but which are NOT appropriate to pkgsrc because they have no
external maintainer.

The "othersrc" collection is currently experimental and subject to
future changes in the way it is managed.

Here are some examples of things appropriate for "othersrc". Note that
these are just examples, not an exhaustive list:

      A game from the comp.sources archives that has no known
      maintainer and isn't available in a "untar and go" archive on
      the net.

      The "cdecl" utility, a useful program that converts complex C
      declarations to English and vice versa, and has no known
      maintainer but needs some work to make it up to date for C89.

An example of something inappropriate for "othersrc" is "perl",
because "perl" is actively maintained and works just fine in
pkgsrc. Another example of something inappropriate would be "ncurses"
which is externally maintained and is fine in pkgsrc.

Programs added to "othersrc" are be expected to follow the following 
rules:

1) No external maintainer: Either the program was written by a NetBSD
person who doesn't maintain any other formal distribution mechanism
for it, or it is some hack found somewhere on the net in the past that
has been long since abandoned by the authors. There should be no
prospect of an external maintainer showing up soon, either.

2) Acceptable license: the source must have an open source license
compatible with inclusion in the tree -- i.e. a near-BSD license or
better. If the code has a GPL on it, we might in the future create an
"othergplsrc" or some such, but for the moment, nothing that could
trip up a distributor of NetBSD derived operating systems should be
included.

3) BSD Makefiles, etc.: after initial import, the code should be made
to conform with NetBSD standards on how code placed into the main tree
should look. It must be built with clean BSD Makefiles, compile
without warnings, be 64 bit clean, etc. It need *not* have prototypes
__P'ed or any other such thing, but it *should* have prototypes and
such added if the code base was K&R prototypeless code to begin
with. Note that if you want to preserve the original Makefile for the
program so that it compiles on other platforms, please rename any
non-BSD Makefile to "Makefile.posix".

4) The code should run on all BSD architectures or (if it requires
some MD work to get it to do so) must be made to do so reasonably soon
after importing. The only exception to this should be small utility
programs that tweak hardware available only on one machine.

5) The code should not be "disruptive" to the existing tree. For the
moment, "othersrc" is installed into /usr/local, but some day it may
be installed into /. Thus, if I type "make install" in any "othersrc"
program directory, it should not add files in places where they do not
belong, overwrite files that would otherwise be installed by the main
tree, etc. Also, the program should not be overly large -- if it adds
fifteen megs of cruft to the tree, its probably something that should
be discussed heavily before it is imported.

6) The code should be of general interest. A CAD system for designing
wristwatches probably isn't appropriate -- its a very specialized
application. A "vanity program" (similar to a "vanity kernel config")
that is useful to only one person should almost certainly *not* be in
"othersrc". A program that lets you do search and replace on symbols
in a large corpus of C code probably *is* of general interest and
would be appropriate. If there's doubt, it should be discussed.

7) I'm not sure if we should or should not accept X utilities. We'll
discuss that when we come to the problem.

Currently, "othersrc" is in an experimental phase. We are still
figuring out how to use it properly and who will want it. Although the
original plan called for "othersrc" being a (second class) part of
releases and being built to /, for the moment it will not be part of
releases and will be built to /usr/local. This will change after we
have gained some experience with it.

During this "experimental" period, we will "play around" with the
collection and see what sort of level of commitment and what sort of
mechanisms are likely to work well. We will play with using the output
in pkgsrc vs. using it in its "native" tree, see what sort of programs
people seem to be finding to import, etc., and get some experience
with the mechanism. We may even change the name of the collection
after thinking about it for a while.

Please contribute!

 		--Perry Metzger