Thomas Klausner wrote:
> Johnny imported a new emulation framework that solves quite a number
> of problems (thanks, Johnny!).

Thanks.  I'm not quite done... I intend eventually to adjust the 
framework to more gracefully specify support for different versions of 
an emulated OS, e.g. Solaris 8 versus Solaris 10, but what I've check in 
now is a good starting point for future work.

> I have a new problem with it:
> firefox-bin-java only exists for linux-i386 (because firefox-bin only
> exists for it); it depends on sun-jre15, for which both linux-i386 and
> linux-x86_64 versions exist. On NetBSD/amd64, the linux-x86_64 version
> is built by default. So installing firefox-bin-java pulls in the
> x86_64 version of the Java plugin and expects it to work in
> firefox-bin.

I wonder if for firefox (and seamonkey), this might be worked around by 
appropriately depending on nspluginwrapper?

> For binary packages it gets even more interesting -- if you build
> sun-jre15, you get the same PKGNAME independent of if you have the
> amd64 or i386 version.
> 
> We probably want to add a way to differentiate the two. Perhaps
> include the EMUL_PLATFORM in the PKGNAME?

This is a variant of the problem of trying to depend on a package with a 
particular set of PKG_OPTIONS (I might have implemented EMUL_PLATFORM as 
a package option, and in practice, it acts just like one).

I think that solving the problem on the "install-from-pkgsrc" side is 
fairly easy, but the same problem on the binary package side is somewhat 
harder.  If we require a binary package to be completely standalone, 
then we must be able to (quickly) determine what PKG_OPTIONS it was 
built with, without needing to unpack the binary package.  The obvious 
way is to encode the information in the filename of the binary package, 
e.g.:

	sun-jre15-5.0.11~linux-i386.tar.bz2
	samba-3.0.24nb3~ads~cups~ldap~pam~winbind.tar.bz2

The only problem is that the filenames can get quite long -- probably 
not enough to hit filesystem limits, but certainly long enough to be 
annoying to deal with.

Lastly, we would adjust the pattern-matching routines in the pkg_install 
tools to parse the three separate parts of a package name -- the base, 
the version, and the options -- and allow for, e.g. samba-3.0.24~cups to 
satisfy samba>=3.0.20.

Using something like the above, we could adjust our DEPENDS syntax to 
allow for requiring specific PKG_OPTIONS, e.g.

	DEPENDS+=	samba>=3.0.20~cups:../../net/samba

We would need to think through the implications of requiring an option 
that the user specifically doesn't want, e.g.:

	PKG_DEFAULT_OPTIONS=	-cups

(I think that the package build or installation should fail), but I 
believe we can figure that stuff out fairly easily.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>