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

Re: appropriate use of /etc/alternatives

On Fri, May 30, 2003 at 03:29:43PM -0400, Noah Meyerhans wrote:

> But they do support the same functionality, just on different formats of
> data file.  There are plenty of cases where a user needs to be aware of

If the input formats are different then the alternative is pretty
useless: you can't use the alternative name since if you get the wrong
program then whatever you're trying to do will fail.

> which specific alternative they're using.  /usr/bin/zsh can run zsh
> version 3 or 4, depending on alternatives.  If the user is going to
> write a script in zsh, he better know which version he's getting,
> otherwise he may write code using a feature not present in the version
> he's running.  On some level, zsh3 is incompatible with zsh4, though
> they both basically do the same thing.  Same with the two
> xplot tools.

It's not that different implementations of an alternative have to be
absolutely identical.  It's that the major point of having an
alternative is that it should be possible to invoke the alternative and
have something sane happen irrespective of which program actually gets

With your zsh example what you're really saying is that if someone
writes a script for the zsh alternative they ought to make sure that
they avoid constructs that aren't portable between different versions of
zsh.  Since it's perfectly possible to do that it's reasonable to have
ab alternative for it.

In the case of xplot it's hard to see how this would work at present.
What you seem to be saying is that neither xplot will cope when
presented with input formatted for the other.  At least the currently
packaged xplot seems to require the data to be provided at invocation
time so it's hard to see how someone could reliably use the alternatve.
If that's not the case and there is a core set of functionality that
works with both implementations then an alternative sounds more

> installed by it.  If we can't use alternatives to manage /usr/bin/xplot
> in this case, my package will simply end up conflicting with the
> existing xplot package, which is neither necessary nor desirable.

The binary is going to have to be renamed - even if you use an
alternative there'll still be a renamed binary there.  

Would it be possible to massage the data format for one xplot into the
other or modify one to accept the input of the other in a compatibility

"You grabbed my hand and we fell into it, like a daydream - or a fever."

Attachment: pgpGV6LnA2J4J.pgp
Description: PGP signature

Reply to: