Re: category

Stefan Karrmann <[email protected]> wrote:
> But one of my questions is still open, how to package and _register_
> GNU (FSF, BSD, etc.) software?

For my slashpackage-foreign project, I have registered misc/spf.
Foreign packages will be installed inside there.  Commands are not
registered at all.  Anyone who wants "ed" to refer to
/package/misc/spf/ed/bin/ed can create a symlink in /command to
express that.  I will provide tools to ease the maintainance of
symlinks in /command.

This is a greedy, impatient solution, though.  It's better to get the
package maintainers themselves to participate.  (After that point,
they will still have to worry about conlicts with traditional command
names, but I think tools like the ones I'm working on will be
sufficient to deal with that.)  That will be an easier sell after our
build systems are more mature.  spf may be useful as a proof of
concept to help convince anyone who doubts that such a system can
work; my systems are now entirely built from source, and entirely
installed in package-specific directories in /package - even glibc.

$ ls -l /bin /sbin /lib /usr
ls: /lib: No such file or directory
lrwxrwxrwx    1 root     default         7 Aug 19 17:48 /bin -> command
lrwxrwxrwx    1 root     default         7 Aug 19 18:44 /sbin -> command
lrwxrwxrwx    1 root     default         1 Aug 19 19:36 /usr -> .

There are still a few parts that need to be polished and published,
though, so don't worry if what you see on my web site doesn't look
complete yet.

> Will Prof. Bernstein refuse all packages/commands which implement existing
> commands?

AFAICT, it doesn't matter what functionality they implement; it only
matters what names they use.  Names that were in use before
slashpackage cannot be registered in the slashpackage registry.  For
such commands, we'll maintain symlinks in /command without help from
the packages themselves; given tools to do that, the packages don't
really need to register any names at all for ther commands.


paul