RE: registration request

I don't really like the categorizing, mostly because it doesn't work for
everything, or stuff happens to be in two categories and you can't find it
if you need.

So I found myself using strictly /package/host, so much so that I decided on
not wasting time on the host part. For example, I put daemontools in
/package/cr.yp.to/daemontools-0.76, and postfix in
/package/postfix.org/postfix-1.07, and so on. It is sufficient to keep the
/package directory to a descent size, since I doubt a machine would have
packages from more than a couple of thousands different companies/domains.

So just put it in /package/host/gnu.org/ed-xx.xx and be done with it (or
/package/gnu.org/...). No need to be bothered about where it fits, as long
as domain registrars do their jobs, you're unlikely to have a name conflict.

If someone wants to categorize it, they can always put a symlink in the
category tree later.

-Mathieu

> -----Original Message-----
> From: Stefan Karrmann [mailto:[email protected]]
> Sent: Wednesday, August 28, 2002 2:13 PM
> To: D. J. Bernstein; [email protected]
> Subject: Re: registration request
>
>
> D. J. Bernstein (Sat, Aug 24, 2002 at 08:44:09PM -0000):
> > Stefan Karrmann writes:
> > > Well, ed is an editor, like emacs, vi, joe, etc.
> >
> > Is sed an editor? Is kword an editor? Is webmin an editor?
>
> sed yes (I know that you would ask it.)
> kword is a word processor
> TeX is a typesetting system
> I do not know webmin
>
> The choice of a category is the fundamental problem of the category
> system of slashpackage, cf. the mailing list archive.
>
> I am open to suggestions - should ed be in
>   prog (most programing language needs an editor),
>   data (ascii/latin1 text is also a (simple) data structure), or in
>   misc (it does not fit into another category)?
>
> How should I integrate ed (and emacs, gcc, X11) into slashpackage if
> the command ed cannot be registed?
>
> Proposal for conflicting implementation:
> ----------------------------------------
>
> Package editor/ed is virtual, i.e. there is no implementation with
> name prefix editor/ed-. The commands ed and red belongs to editor/ed.
>
> Package editor/gnu-ed-0.3 is an implementation, like editor/foo-ed-42,
> etc.
>
> Variant 1:
> ----------
> Symlink editor/ed to editor/gnu-ed-0.3. This is quite simple, but
> everytime you update gnu-ed you have to update the symlink.
>
> Variant 2:
> ----------
> Symlink editor/ed to editor/gnu-ed. This fixes the cons of variant 1,
> but if a package manager links every name in the subdirectory command
> of every current version from /command it will get a conflict!
> Well, it may ignore conflicts if they point to identical inodes (and
> choose the one which points to the other).
>
> Variant 3:
> ----------
> editor/gnu-ed has no subdirectory command but cmd-loc. To choose it
> as the current implementation symlink all names in cmd-loc from
> editor/ed/command.
>
> My favorite is 2 although it complicates a package manager.
> --
> Stefan Karrmann
>