Subject: Re: Depending on a particular version of an emulation package
To: None <tech-pkg@NetBSD.org>
From: Johnny C. Lam <firstname.lastname@example.org>
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
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
Using something like the above, we could adjust our DEPENDS syntax to
allow for requiring specific PKG_OPTIONS, e.g.
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 <email@example.com>