Subject: Re: Alternatives in the same package
To: Julio M. Merino Vidal <jmmv84@gmail.com>
From: Mike M. Volokhov <mishka@apk.od.ua>
List: tech-pkg
Date: 04/25/2005 10:17:07
On Fri, 22 Apr 2005 23:57:00 +0200
"Julio M. Merino Vidal" <jmmv84@gmail.com> wrote:

> On Wed, 2005-04-20 at 17:58 +0300, Mike M. Volokhov wrote:
> > On Wed, 20 Apr 2005 16:42:38 +0200
> > "Geert Hendrickx" <geert.hendrickx@ua.ac.be> wrote:
> > 
> > > On Wed, Apr 20, 2005 at 02:51:07PM +0300, Mike M. Volokhov wrote:
> > [snip]
> > > > Any opinion, how to create such packages?
> > > 
> > > I'd suggest to split the package up, so there will be "binary" packages
> > > for both the perl and the ruby version.  
> > 
> > That's exactly what I had done. 
> > 
> > > pkg_alternatives aren't necessary as there is no need to have both
> > > installed.  It's not a matter of different interfaces (thus user
> > > choice), just different dependencies (so only the sysadmin cares).  
> > 
> > My packages will install xmlformat.pl and xmlformat.rb respectively.
> > However, both packages are powered by alternatives framework, so
> > sysadmin may bound any of both scripts to xmlformat. For people without
> > alternatives, short name may be assigned via shell aliases.
> 
> I still don't understand why you chose to use alternatives (and this
> is what the previous post asked, if I understood it correctly).
> 
> Is it there any difference, from the user point of view, when using
> xmlformat.pl instead of xmlformat.rb (and viceversa)?  If so, then
> using alternatives is correct because each user will be free to use
> the version he prefers.
> 
> If not (i.e., both programs are exactly the same but coded in
> different languages), this could be simplified by making each
> package install the xmlformat "binary" and adding conflicts against
> each other.  After all, only the administrator will care about the
> version used (due to its dependencies).

Okay,

seems too many people prefer don't use alternatives in such packages.
If so, I'll convert both to mutualy exclusive ones. Thanks for the idea.

But to address further questions, is anywhere explained where to use
alternatives and where to not?

--
Kind regards,
Mishka.