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

On Mon, Jun 23, 2003 at 03:00:06PM -0400, Paul Jarc wrote:
> "Nicholas E. Walker" <[email protected]> wrote:
> > How about defining the set of directories living in / and what they
> > all do?
> 
> <URL:http://cr.yp.to/slash.html> would seem to be an effort in that
> direction.

Rephrased: in the reformulated system shall-we-call-it distribution what
directories would be in the root and what would their purposes be?
Presumably Paul does not have all of the directories and files listed in
cr.yp.to/slash.html extant in his /package-based system.

> > What are opinions about locating libraries?  A 'slashlib' or
> > 'slashlibrary' like slashcommand, or do they stay under /package?
> 
> They can stay in /package.  It's easy enough to refer to them by full
> pathnames.  Flattening the namespace requires more coordination among
> developers.
> 
> > What about making ports (e.g. Paul's sp-foreign) first-class citizens of
> > the sp hierarchy?
> 
> Stefan Karrmann registered text/gnu-ed-sk for his "port" of GNU ed.
> Is that the sort of thing you had in mind?  (The word "port" doesn't
> seem quite right to me.)

"Port" seems just as appropriate here as in the case of the BSDs.  Given
that code is being modified or wrappers are being generated, there is a
modification of the original package for the sake of compatibility.  Is
that not a port?

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.  

Let me rephrase my original question:

In /package, do 'foreign' packages belong integrated into the
classification system outlined by DJB or do they belong under a
secondary hierarchy?

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

> > What about an extension to the slashpackage format along the lines of
> > making /package/..../command be a symlink to command-$(syst), allowing
> > for precompiled tarballs and the ability to serve heterogenous systems
> > from a single /package tree?
> 
> Have you read <URL:http://cr.yp.to/slashpackage/sharability.html>?

That document does not address the issue of distributing precompiled
packages.  I understand that some personalities on the list may be in
favor of compiling everything from source when installing on a new
system.  Let me tell you sometime about how much fun it is to natively
compile a kernel or GCC on the embedded hardware I work with.  What I
perhaps too briefly attempted to indicate for discussion was the
structuring of tarballs including object files and/or linked binaries.

Curtly pointing me at that document does not address this issue.  The
document does address sharing /packaged packages but not the issue of
distributing targeted objects.  Using the /shared hierarchy does not
make sense for e.g. an embedded system.  Being able to install a
precompiled package does.  Being able to share that precompiled package
with others does.  Providing that package to others in such a way so
that it can coexist nicely with otherly-targeted versions of the package
does.

It is feasible to produce a tarball that can either be written as part
of a ROM image or be extracted on a server to be used by an NFS-rooted
client.  The structure could perhaps be like this:

daemontools-0.76-linux-arm7tdmi.tar.gz:
/package/admin/daemontools-0.76/
/package/admin/daemontools-0.76/command-linux-arm7tdmi/
/package/admin/daemontools-0.76/command-linux-arm7tdmi/svscan
.....

I could install this on to the embedded device or my linux-i686 without
creating any problems or introducing the /shared hierarchy.  The package
installation tools could be modified to understand cross-compilation at
least to the degree that they would install object files in a directory
with the target appended to the name.  To affect minimal change,
"command-$(target)" could be linked to "command" when $(target) is the
host.  To allow direct exporting of the /package hierarchy, symlinks
could be made as:

/command/svscan -> /package/admin/daemontools/command-linux-i686/svscan

In the worst case, where there is no need for multiple targets
installed and etc., the only loss is the extension of 'command' to
'command-linux-i686'.  In my case, I have a more useful packaging system
with minimal, optional, complexity.  In the central-NFS-server case,
standard tools or scripts can handle relocating the right bits to the
right places in /shared on the server with less complexity, since the
system already takes multiple targets into account.

Comments?

Nicholas