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

"Nicholas E. Walker" <[email protected]> wrote:
> That 'ed' is under /package/text and 'gcc' is under /package/misc/spf
> indicates a lack of coherency and needless complexity.

As it happens, ed is not actually under /package/text, AFAICT.  Stefan
registered the name, but never got around to publishing a package.

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

A secondary hierarchy acts as a delegation point, so it's easier for
me to add new packages to spf; I don't have to make a new registration
for each package, since all names under /package/misc/spf/ are already
delegated to me.  That's not necessarily an argument for one scheme or
the other, but more of an explanation of why I did my system this way.

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

Actually, sp-foreign supports ed, and already did when Stefan
registered his package name, I think.  Stefan thinks, as you perhaps
do, that there should be only one hierarchy.  So this issue is not
new.  (But not yet settled, either.)

> What I perhaps too briefly attempted to indicate for discussion was
> the structuring of tarballs including object files and/or linked
> binaries.

They can look just like source tarballs, except that they would also
contain the binary files for one particular platform, and would
perhaps not include the source files.  The package/compile script
would have to be changed into a no-op, etc., but it's not a hard
problem.

> Using the /shared hierarchy does not make sense for e.g. an embedded
> system.  Being able to install a precompiled package does.

The two ideas are not mutually exclusive.

> Providing that package to others in such a way so that it can
> coexist nicely with otherly-targeted versions of the package does.

Coexistence with other targets is the part handled by /shared.  It
happens that /shared does double-duty as a network mount point.  Maybe
the two functions should be factored into separate paths, but
regardless, we can use /shared for just one purpose and not the other,
if that's all we need.

> I could install this on to the embedded device or my linux-i686 without
> creating any problems or introducing the /shared hierarchy.

You seem to imply that there is something about /shared that you don't
like.  What is it?

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

That would require changes to each individual package.  OTOH, /shared
works right now, even with packages that don't anticipate it.


paul