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

Um, actually, they do.  The tarballs are built using scripts and set
lists.  they've had the md files stuffs ince forever, and I added teh
arc-specific and toolchain-speciifc files a while back.  see
/usr/src/distrib/sets/{makeflist,lists/*].

>and none you will want to add that layer to
>pkg_*.

Nope, strictly only to the scripts that build the system pkgs which go
into pkg-sets. But my experience says it'll help in the pkg-build
stage as well, especially as ports migrate to ELF.


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

>The merging of MD/MI PLISTs is done by the pkgsrc *build* system,

OK.  So add the arch-dependent/toolchain-dependent stuff there, too.
It's the right way to go.


I think we're at cross-purposes here. I dont think we shouldnt be
using that pkgsrc builts for our own intree source, anyway.  I'm
suggesting something more like the existing set-lists and
maketars/makeflist, run after a `make distribution, but which builds
the system pkgs, then wraps them into a pkg-set (tarball plus CONTENTS
plus sizes?).


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

No, not sufficient, IHMO.  Because those are pkg_level, and you might
choose not to install the pkg that replaces a given obsoleted file.