Subject: Re: Depending on a particular version of an emulation package
To: None <>
From: Johnny C. Lam <>
List: tech-pkg
Date: 07/30/2007 17:30:49
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, 


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.:


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


	-- Johnny Lam <>