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

> Rephrased: in the reformulated system shall-we-call-it distribution what
> directories would be in the root and what would their purposes be?

 This depends heavily on the purpose of your distribution. For instance,
if your system is going to be a NFs server, you'll have /shared ; else
you won't. If your system is going to have a single disk partition,
you'll have /package and /command ; but if you want to separate
emergency/boot-time commands from "normal use" ones, you'll have
something like /rootfs and /usr, both having package and command
subdirectories, and /package and /command being a dir containing
a forest of symlinks to the right directories, a la update-symlinks
(http://www.skarnet.org/software/symtools/)

 If you intend to maintain compatibility with standard Unix tools such
as login, you'll have /etc ; but if you want to have another, better
configuration system homed in /package, then /etc won't exist.
And so on, and so on.

 Since a /package-based system has only been tried individually, there
hasn't been much concertation, and no standard has been proposed.
We could use this list to try and establish such a standard (if DJB is
OK with that, for it goes well beyond /package) but I'm not sure whether
it's possible to design a filesystem hierarchy that does the right thing
in every case.


> What I was intending was to clarify is how 'foreign' packages should
> take a place when being integrated into the /package system.  Putting
> everything under /package/misc/spf creates an irregular classification
> for packages that seemingly should belong under e.g. /package/prog for
> gcc.
> 
> That 'ed' is under /package/text and 'gcc' is under /package/misc/spf
> indicates a lack of coherency and needless complexity.  

 That's less a problem than having to repackage the world, which is a
mistake made by too many distributions. See
 http://cr.yp.to/compatibility.html

 In other words: repackaging is Bad. (I wasn't convinced the first time
I came here ; now, as a software author who wants to be able to get
useful bug-reports with reproduceable behaviours, I totally agree.)

 Installing a piece of software under /package/misc/spf/foobar is fine:
most software authors explicitly support installation under a
"non-standard" root. GNU configure scripts make that easy, if there's
one thing they make easy. :)
 On the other hand, patching the software - which most repackaging
systems do - shifts the responsibility from the original author to you.
It's okay for one or two packages, but insane for a whole distribution.
The main principle is: don't change the way the author intended the
software to be used.


> I am asking this because the issue is unclear.  Does GNU ed belong under
> /package/text, or should Stefan have submitted a patch to Paul for
> sp-foreign?  Paul has created something of a divergent de facto
> standard.

 I believe that ed's place is /package/misc/spf/ed .
 If Stefan wants to provide a gnu-ed-sk package, with a gnu-ed-sk
command which is based on GNU ed, fine. But it's gnu-ed-sk, not ed,
and Stefan, not the ed maintainers, is responsible for the gnu-ed-sk
software. He's creating work for himself.


>  If Paul is doing the right thing by putting foreign packages
> under a secondary hierarchy, it seems sensical to allocate
> /package/ports for the purpose instead of using /package/misc/spf.

 I see no sensible difference between /package/ports and
/package/misc/spf. It's only a convention, and we have one that works,
so why change ?


> That document does not address the issue of distributing precompiled
> packages.

 This is a whole other subject.
 There are a number of problems with precompiled packages - some of them
technical, some of them legal. For instance, under which licensing terms
should a precompiled package be distributed ? I'm the author of execline,
which is BSD-licensed ; I want to distribute a binary execline package,
statically linked against the diet libc, which is GPL. Can I even do that
without explicitly putting the binary package under the GPL ? More
difficult: can I distribute a statically linked qmail, knowing that the
diet libc is GPL, but the binary qmail package won't be modifiable at all ?

 And, if you want a /package-based djb-like binary distribution, help us
persuade DJB to release versions of ucspi-tcp, djbdns, qmail, libtai and
friends that install by default under /package, so that we can comply to
http://cr.yp.to/distributors.html  :)

-- 
 Ska