On Sun, 18 May 2003, Jeff Rizzo wrote:

> So, I just started playing around with syspkg the other day, and
> it's got a lot of potential, but looks like it's suffered a little
> bitrot since its initial commit over a year ago.  I noticed that

Yes, it has. It's worst problem is that it doesn't support unpriv'd
builds, and a #2 problem is that it doesn't seem to do DESTDIR builds so
well.

> a few packages are referred to in the setlists that don't have
> corresponding packages in the distrib/syspkg/sets directory.  So,
> I figured this was a good way for me to help out, and I've started
> creating packages for this missing stuff, which I'll send-pr
> shortly
>
> As I work on it, though, I've noticed a couple of areas where
> there doesn't currently seem to be a good answer, unless I'm
> missing something (which is likely the case).  One of them
> is the handling of machine-dependent files or lists - the
> current packages seem to have a largely i386 slant to them.
> Is it OK to just add MD files to non-machine-specific syspkgs?
> For example, the i386-specific (and amd64, I guess)
>  "./usr/mdec/pxeboot_ia32.bin" shows up in the PLIST for
> base-sysutil-bin, but the macppc-specific "./usr/mdec/ofwboot.elf"
> does not, despite it being labelled as such in
> distrib/sets/lists/base/md.macppc .  I'd be happy to do some
> work in this area, since I've currently got an interest in fine-grained
> control of system installation, but I wanted to check with the list
> first to see if anyone had any ideas or perhaps was already
> working in this area...

For everything other than /usr/share, as I understand syspkg, it's fine to
have MD files in "mi" packages, as the packages aren't really MI. Since
our binaries are machine-specific, packages of them will also be machine-
specific.

Also, I thought the idea was that the lists were built per-machine. Thus
the md.$MACHINE and ad.$MACHINE_ARCH files would get pulled in, making the
packages correct for that machine. Thus the sets built on an i386 won't
have ofwboot.xcf, but the ones built on a macppc would.

Well, that is how I thought it is supposed to work. It might not work that
way.

As above, the problems I see are:

1) Doesn't deal with DESTDIR. The original idea was you install the
system, then you make syspkgs of it. This is how the pkg system works,
thus it makes/made sense. To work with DESTDIRS, obviously, we need to
play with the files in the DESTDIR. One issue is (was) that it wants to
deal with the syspkg database in /var/db/syspkg (think that's it). For
DESTDIR, needs to be $DESTDIR/var/db/syspkg

2) Doesn't deal with unprived builds. This means a) that the pkg-up
code wants to be root, since it expects it's playing with
/var/db/{sys}pkg, which requires root access. Unprived builds obviously
don't have this issue _and_ need to _not_ be root. b) Doesn't understand
METALOG, which might only be a command option passed to its calls to pax.

3) When the above are fixed, syspkg needs to be hooked into build.sh, so
that it's as easy to build a syspkg release as it is to build a non-syspkg
release.

Take care,

Bill