Re: djblinux/djbos/"D. J. Bix"

Laurent Bercot (Thu, Jun 26, 2003 at 01:18:06AM +0200):
> > I think text/gnu-ed belongs to the FSF. While text/gnu-ed-sk belongs to
> > me.
> 
>  I don't expect the FSF to go /package: text/gnu-ed won't be registered.
> Then again, _why_ want to register ed in /package ?

A /package-OS should be autarchic. It should not rely on old standards, IMHO.

>  If you want GNU ed on your /package-based system, install it in
> /package/misc/spf/gnu-ed or whatever, and invoke it via
> /package/misc/spf/gnu-ed/command/ed . That way you'll have cheap
> alternatives. If I'm rewriting ed someday, I'll call it
> /package/host/skarnet.org/ed/command/ed . You choose which one you
> want to use by specifying the absolute path, or by $PATH.
> 
> > (2) D.J.B. has to fix this part of his policy for eternity. While another
> >     registry has to be set up for alternatives of global commands. In
> >     general the different alternatives are more or less incompatible.
> >     Thus, the registry should define a (or the greatest) common
> >     interface for clients.
> 
>  This is _really_ hard to do. There are some standards trying to
> accomplish this, for instance Single Unix, and not even modern Unices
> are SUS-conformant. For instance, FreeBSD's glob() function and
> GNU's bash program do not follow the glob() and sh specification
> respectively.

But there is something in common. E.g. every bourne shell has `if' but
not necessarily functions, c.f. autoconf.
Non-common features should be labeled as obsolete and
non-deterministic with respect to different implementations.

>  /command is great, but I agree with DJB on this point: currently
> existing names should not be registered in /command . /command
> should be an _absolute_ guarantee that the given command will do
> exactly what you're expecting it to.
>  Then, on your own system, if you believe that GNU ed conforms to a
> standard that suits you, you may well have a link /command/ed ->
> /package/misc/spf/gnu-ed/command/ed ; but that's a decision for
> system administrators to make, not distributors.

If I use locally /command/foo and someone else registered it, I'm in
trouble. Thus, every command in /command, even local ones, should be
globally registered. C.f. the discussion on this list about
non-registered categories in /package.

The distributer should offer a method for alternatives, because this
will be a common task. The CHOICE is the task of the system
administrator.

-- 
Stefan