I'm working on allowing netbsd-${EMUL_ARCH} to be valid EMUL_PLATFORM 
types for binary-only software.  Binary-only software is software which 
is only available as a binary, e.g. F-PROT AntiVirus for BSDs 
(security/fprot-workstation-bin).

As part of this work, I notice that our emulators/compat* packages are 
not very good.  I would like to change them as follows:

     compat12 has shlibs from NetBSD<1.3 not in NetBSD-1.3.3.
     compat13 has shlibs from NetBSD-1.3.3 not in NetBSD-1.4.3.
     compat14 has shlibs from NetBSD-1.4.3 not in NetBSD-1.5.3.
     compat15 has shlibs from NetBSD-1.5.3 not in NetBSD-1.6.2.
     compat16 has shlibs from NetBSD-1.6.2 not in NetBSD-2.1.
     compat20 has shlibs from NetBSD-2.1 not in NetBSD-3.1.
     compat30 has shlibs from NetBSD-3.1 not in NetBSD-4.0.

The shared libraries are always taken from the latest release along each 
NetBSD branch.  This set of packages can be installed without any conflicts.

If you are running NetBSD-3.0 and you would like to run a NetBSD-1.4 
binary, then you would install compat14, compat15, compat16 and 
compat20, which would provide the complete set of shared libraries needed.

There would also be some other package that would install ld.elf_so and 
ld.so for the benefit of compat_netbsd32-capable systems.

The netbsd32_compat* packages would be handled similarly to the way that 
suse32-*/suse-* packages are handled, so that, e.g. NetBSD/amd64 would 
be able to use a package that supports netbsd-i386 emulation without 
needing any magic.

Any thoughts on this before I start modifying these packages?

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>

P.S.  Going off on a tangent, I guess if you were running NetBSD-3.1, 
you could install your packages with:

     (1) bootstrapped tools
     (2) LOCALBASE=/sw/pkg/3.1
     (3) PKG_DBDIR=${LOCALBASE}/.pkgdb
     (4) /usr/pkg as a symlink pointing to /sw/pkg/4.0

Then if you upgrade to NetBSD-4.0, you could install compat30 and your 
/usr/pkg binaries would continue to work.  Then you could slowly 
populate /sw/pkg/4.0 with new packages to supplant the ones in 
/sw/pkg/3.1, and when you're done, just do away with the old pkg tree. 
This seems potentially useful.