On Wed, 20 Apr 2005 14:00:20 +0200
Quentin Garnier <cube@cubidou.net> 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 documentation,
> > independly what kind of script you use. The xmlformat-ruby and
> > xmlformat-perl will be bounded together via PKGALTERNATIVES framework.
> 
> 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...

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

--
Mishka.