Subject: Re: Alternatives in the same package
To: Mike M. Volokhov <>
From: Quentin Garnier <>
List: tech-pkg
Date: 04/20/2005 15:04:24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 20, 2005 at 03:35:15PM +0300, Mike M. Volokhov wrote:
> On Wed, 20 Apr 2005 14:00:20 +0200
> Quentin Garnier <> wrote:
> > On Wed, Apr 20, 2005 at 02:51:07PM +0300, Mike M. Volokhov wrote:
> > [...]
> > > 1) Split package on three chunks - xmlformat-ruby, xmlformat-perl,
> > > xmlformat-docs. Latest package will contain only support documentatio=
> > > independly what kind of script you use. The xmlformat-ruby and
> > > xmlformat-perl will be bounded together via PKGALTERNATIVES framework.
> >=20
> > That's what you should do, I think, except for the part that involves
> > alternatives:  a user will want either versions, not both, unless it is
> > a package likely to be used by some other packages that might invoke it
> > in Ruby or PERL.  In the latter case, both versions should be installed,
> > or each package installing an appropriately named version of the script.
> > Again, no alternatives framework involved.
> Hmm... Seems I haven't understand alternatives job. When we have two
> programs created to solve just the same tasks in the same way, for
> example, editors nvi and vim, it's time to use alternatives, right?
> But now we have just the same programs, both should be better installed
> as bin/xmlformat. Why not use alternatives here? Moreover, who want to
> have both nvi and vim? But alternatives were defined there...

nvi and vim are different programs that offer a common interface to do
similar things.  In your case, one program is offering two interfaces to
do the exact same thing.  While I get your point, using the alternatives
framework look like complete overkill to me.  But in the end it is your
choice anyway.

> > > 2) Use variable named, say, USE_LANG which may be set to "ruby" or
> > > "perl" at the build stage. Resulted package name may be also dependent
> > > on the selected value for USE_LANG. The conflicts will be also handle=
> >=20
> > In that case, the correct way of doing this would be with the
> > PKG_OPTIONS framework.
> Yes, that's it. Thus yet another question about PKG_OPTIONS. Is it
> possible to create mutualy exclusive pkg options? This might be useful
> for option switching.

You can test on ${PKG_OPTIONS} and then set PKG_FAIL_REASON.

Quentin Garnier - -
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)