[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When to use "Replaces"?



On Tue, May 31, 2016 at 05:13:14PM +1000, Scott Leggett wrote:
> On 2016-05-30.21:22, gregor herrmann wrote:
> > On Mon, 30 May 2016 20:25:56 +0200, Adam Borowski wrote:
> > 
> > > >   c) Something else ...?
> > > As both unclutters provide generally the same functionality, you may also
> > > use the "alternatives" method.  
> > 
> > My impression is that the "new" version has different command line
> > options. So calls to unclutter with the old options in
> > .xsession/.xinit would break if /usr/bin/unclutter points to the new
> > implementation via alternatives.
> > 
> > I think I'd go for renaming here.
> 
> Using the alternatives system is an interesting idea. Yes, the "new"
> version is *not* a drop-in replacement - while the functionality is the
> same, accepted arguments are not totally identical. However the
> description and example given in the policy manual of different "vi"
> clones seems to match the "unclutter" situation quite well.

I can't seem to find a relevant definition in the Policy, so here's my
common-sense reasoning:

is the primary use mode compatible?  That is, will the usual mode of
invocation of one alternative work with the other?  For example a vast
majority of invocations of "editor" is just "editor $FILENAME"; comparing
command-line options of jstar and vim the only one that seems to be common
to both is +$LINENUM -- and even that is not officially mandated anywhere.

It's obvious arguments will almost never be totally identical -- different
implementations have different features and different needs.  That's ok and
expected.  I'd say such programs are unfit to be alternatives to each other
only if the usual, basic functionality needs different invocations.

> Am I correct in understanding that using alternatives requires
> co-operation between the two packages, "unclutter" and
> "unclutter-fixes"? If that's the case, I'll approach the "unclutter"
> maintainer, and if they disagree on using alternatives, will just rename
> my package.

Yes, all packages in an alternatives set must cooperate.


Meow!
-- 
An imaginary friend squared is a real enemy.


Reply to: