[Cc:ed to tech-install since this makes no sense unless our install
tools grok it, too.]

On Tue, 29 Sep 1998, Jonathan Stone wrote:

[ setfile mechanism supports arch-, toolchain- specific contents]

>>I hope we dont lose that entirely;) but see below.

>This is one of the major areas which needs to be fleshed out.  The
>mechanism I propose is that each set build directory will contain a
>directory for each package in that set.  Each package will have a set of
>PLISTs just like with current pkgsrc packages.

What I'm trying to say is that static file lists _dont work_, if what
goes in a system package is arch- or toolchain-dependent (or
equivalent, if which pkg of several alternatives goes into a pagage
set depends on the target arch.)  I'm thining of things like ld.elf_so
vs ld.so, and the ELF symlink farms for shared libs.


>Right now, third-party packages can have multiple PLISTS, one containing
>MI files, and MD files varying by type of platform, or by nearly
>arbitrary conditions (mysql client or server PLISTS, or xemacs
>PLISTs with or without MULE support to pick to examples).  Hopefully
>this can be done in a standard way that will be easy to maintain.

Yup.  I'm saying we want to add an arch-specific and a
toolchain-speciifc layer on top of that, like I did for the
install-sets listfiles some time back.  It actually tidied things up a
lot; most of the supposed "machine-depndent" contents were actually
object-fmt dependent, and a few were arch-dependent.

If the pkg-building tools have that flexibility it comes down, I
think, to partitioning the existing sets files up into PLIST files.


[ increased sharability]

>>This seems a very good time to start tackling this, too.

>A good point.  Perhaps the division into packages should keep this
>goal strongly in mind, so that there are at least MD and MI packages.
>This would make it easy to split into MD and MI sets as well.

that's why I broguht it up ;-)

>At any rate, I strongly believe that the division of our current sets
>into packages should be done such that no package installs into more
>than one of /, /usr, /usr/share, and /usr/X11R6.  At the least, all
>/usr/share packages will thus be MI.

The obvious gotcha here is that we were talking about making _sets_
more sharable. If we go the package route, it'd be nice to let the
user select ``install compilers''or ``install text-processing stuff''
and both the binaries and the associated stuff in /usr/share.
But, yes,  I think i agree.

And the big item that's not on your list is how to deal with upgradesn
from a pre-pkg system -- i.e., removing any old files from components
that aren't installed.  (We've needed this since programs started
moving from /sbin/ to /usr/sbin, Even if you install all the system
pkgs-sets, we still need a way to do that-- let alone when you do a
"tailored" install.)