Off by one in kernel version incompat list for emulators/compatNN pkgs

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The compatability packages for older versions of NetBSD are all set to
not build on a NetBSD that is too old - that's sane, it makes no sense
to pretend it is possible to be compatible with NetBSD 4 if you're just
running NetBSD 3 (or anything similar).

But (ignoring the NETBSD_COMPAT32 case for now, as I haven't really thought
about that one) I think there's an off by one in the ONLY_FOR list
in the packages.

That is, taking emulators/compat40 as an example ...

        ONLY_FOR_PLATFORM= NetBSD-4.99.*-* NetBSD-[5-9]*-* NetBSD-[1-9][0-9]*-*

(I changed white space a little so the line would fit 80 cols after indenting
for this e-mail).

That says that it isn't possible to build or install emulators/compat40
unless you're doing it on a system that is newer than NetBSD 4 (that is,
NetBSD 5 or later, or one of the 4.99's on the way to NetBSD 5).

The "or install" part is probably correct, it doesn't really make a lot of
sense to install NetBSD 4 compat libs on a NetBSD 4 system (though if it is
done carefully, I don't see that it should do much harm either - just a
waste of space, and perhaps a potential for confusion).

But the "build" part is I think wrong, it is necessary to be able to
build the compat packages for the same version system as is being used
to build them.

The reason for this, is that the purpose of these compat packages is
so that you can run binaries compiled for (in the case of this example)
NetBSD 4.0 on later systems.   If you're running NetBSD 4.0, and building
binary packages, they're being built to run on NetBSD 4.0 (or later)
systems.   I do this all the time - build packages against what is
essentially my lowest common denominator NetBSD system, then the exact
same package will run on all the NetBSDs I have to install it on, including
those which (for hardware support, or any other reason) are running later
NetBSD kernels and userlands.   [Aside: I know there are a (very small)
handful of packages where this doesn't work, and which need to be built
on the system they're to run on - mostly I just ignore them, none are
really all that useful for anything - lsof used to be, but is not any more.]

If these packages that are built against NetBSD 4.0 are later installed
on NetBSD 5, they (or some of them anyway) need the compat40 (and
compat40-extras) packages installed in order to resolve the libraries
they need (the one I noticed was wireshark which needs libcrypto which
moved from libcrypto.so.3 to libcrypto.so.4 between NetBSD 4 and NetBSD 5).

But since my package building system is NetBSD 4, I don't get to build
the compat40 packages, so they're not available when they need to be
installed on later systems.

I know the way that package building is (generally) done this is not
easy, as the packages get installed, then the binary package built from
there, and it is perhaps advisable to avoid installing the compat
packages on the same system they're to emulate.  But these packages
don't really need all that - there's no build involved, all that
happens is that the NetBSD 4.0 (in this case) binary libraries get
bundled up (with the admin files) into the binpkg tgz file.
I don't know if these compatNN packages have been modified to
implement DESTDIR support, but if not, doing it should (I think)
be trivial, and in that case, building the binary package on the
same system that's building it should cause no problems at all.

I also know that this is going to require some mods to the way the
ONLY_FOR (etc) tests are done - we really need to distinguish the
systems that can build the package, from those that can install it
(which will also most probably be needed as one of the steps towards
allowing cross-compiling of the packages where that's possible, so
this wouldn't necessarily be a lot of work for little gain.)

I am not plsnning to send-pr this (unless someone feels that it is
important) - just initiate a discussion on how this ought to be
handled in general.

kre