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

> 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 ?

 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.
 That's why I would be _very_ cautious about a global namespace for
"standard" commands. Unless we are rewriting the world in /package
to make it SUS-compliant, there is no way to be 100% sure that a
command will perform as expected. And I'm not using a command unless
I'm 100% sure of what it does.
 /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.

-- 
 Ska