On Wed, 20 Apr 2005 15:04:24 +0200
Quentin Garnier <cube@cubidou.net> wrote:

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

Well, the Ruby variant is a complete rewrite of the initial Perl script.
But this work was done by the same author and thus included in the same
tarball.

In any case, thank you for advice. I'll create three separate packages.

[snip]
> > 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.

It's suboptimal for a big number of mutex options (in this case a
number of tests will grew up by exponential regression), but it's
needed very rare. I've asked just for the future.

Thanks again.

--
Mishka.