packaging system (was: Re: GCC 3.3.2 kernel)

[Chris Pressey]

On Thu, 30 Oct 2003 21:18:26 -0500
David Rhodus <drhodus at xxxxxxxxx> wrote:

> I'd love to see someone bust some code out for this issue.

If not code, maybe we can at least go from stating vague desires to
giving concrete examples?

I think we can agree on some of the following points (bearing in mind
it's still too early in the morning for me to think clearly about this):

- Better standardization than the FreeBSD ports tree.
-- don't just encourage porters make up whatever knobs they like
(look at the USE_* WITH_* WITHOUT_* mess.)
-- standardized knobs for installing a development package ("dev") and
documentation ("doc") as an additional part of a port.
-- standardized naming convention.  The name of the directory in which
the port skeleton resides should have some (consistent) relationship to
the actual name of the package.
- Port hierarchy: I'm sort-of against it.  If you have a web search
engine, do you put it in www or textproc?  You resort to 'virtual
directories'.  Perhaps it's a limitation of the file system?  But I do
think things like 'www' and 'textproc' are more *keywords* than
categories.  A concordance can always be generated, for searching.
- Data format: I don't really care.  As extremes, XML and Makefiles can
both be shown to work.  But, we already have a "hierarchical container
for information" called the filesystem, and barring the previous point,
maybe that can be made to work too.

So what I'm thinking is (assuming a portbase called /usr/ports/):

usr/
  ports/
    k/
      killerapp/
        INFO/
          description.txt
          keywords.txt
          contributors.txt
          licenses.txt
          urls.txt
          ...
        2.1088/
          build/
            settings/
              knobs.txt
              dependencies.txt
              packinglist.txt
              ...
            script/
              pre-fetch.sh
              post-install.sh
              ...
          devel/
            packinglist.txt
            ...
          doc/
            packinglist.txt
            ...
          dist/
            killerapp-src-2.1088.tgz
            ... (any other d/l'd src files)
          patch/
            aa-killerapp__src__Makefile.patch
            ... (any other patches)
          pkg/
            killerapp-2.1088-DragonflyBSD-1.0-i386.pkg
            ... (any other pkg files created by build)
        2.3/
          build/  ...
          devel/  ...
          doc/    ...
          dist/   ...
          patch/  ...
          pkg/    ...
        cvs/
          build/  ...
          devel/  ...
          doc/    ...
          dist/   ...
          patch/  ...
          pkg/    ...
        ...
     ...
   ...

Intended only to spark the imagination and conversation.
In fact, please DO find things wrong with it!
Keeping in mind that file extensions are more or less arbitrary - the
text files might not even be text files, they might be XML files, or
just subdirectories of tiny text files where the filename maps to a
setting's name and the contents map to a setting's value a la some of
djb's config stuff.

-Chris