Subject: Re: CD distributions
To: Jason Thorpe <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: current-users
Date: 02/23/1998 12:00:12
Jason Thorpe <> writes:

>On Mon, 23 Feb 1998 11:13:53 -0800 (PST) 
>Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:


>> Splitting base and comp into ${MACHINE_ARCH}-shareable and truly
>> ${MACHINE}-specific would fix that. It'd mean more changes to
>> release(7) and install tools, though.

>It's worth noting that release(7) specifically addresses this issue
>by allowing a ${MACHINE_ARCH} branch in the tree, and symlinks.

Yes, I know, I'm one of the people who asked it be added :).

But you've missed my point.  Sure, release(7) has a ${MACHINE_ARCH}
branch.  The m68k ports already use that where appropriate (e.g., X11 sets).

But we can't create a shared m68k comp.tgz, because comp.tgz currently
contains some files which are CPU-specific. One example is the macros
which cpp predefines on a given port; also /usr/include/machine.

The first case could be fixed with binding at runtime based onuname.
The latter requires more thought, like shipping all the m68k
/usr/include/${MACHINE_ARCH} directories and moving one to
/usr/include/machine at install time.  And there are probably other
gotchas waiting too. So...

I'm suggesting that we split comps.tgz into two parts, one sharable.
across all ports of a given ${MACHINE_ARCH}, like the gcc backend, and
one with truly machine-specific contents, like /usr/include/machine.
(The same issue may still arise for base.tgz even with the unified m68k
userland -- port-specific binaries -- but I havent looked.)

This split means _more sets_ in toto, but fewer copies of the m68k
userland binaries and libraries. The names of any existing sets that
get split should probably change, for obvious reasons.

Obviously the ${MACHINE_ARCH} binaries would go in the ${MACHINE_ARCH}
branch so they can be shared. But the split itself would, as I said,
mean changes to release(7) and to our install tools.