Subject: re: PROPOSAL: NetBSD System Packages (LONG)
To: Jim Wise <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/29/1998 21:52:41
[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