[CC: list greatly reduced]

On Tue, 29 Sep 1998, Jonathan Stone wrote:
> 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
> ...
> 
> If the pkg-building tools have that flexibility it comes down, I
> think, to partitioning the existing sets files up into PLIST files.

Well, tar (or whatever's used to create the binary tar-files now) doesn't
have that flexibility either, and none you will want to add that layer to
pkg_*.

Instead, you want to do the same with pkg_create what we do with tar now:
merge several files into one list, and then hand that off to
tar/pkg_create (see the latter's -f option). 

This is not a problem of the pkg-building tools.

The merging of MD/MI PLISTs is done by the pkgsrc *build* system, and then
handed over to the binary packaging system (pkg_create). (In pkgsrc, one
can easily provide it's own PLIST - possibly machine-generated on the fly
- by setting the PLIST_SRC variable to that file). 


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

pkg_* support install- and deinstall-files, even prerequirement-checking
scripts. Should be sifficient, no?


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>