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 run. 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 reasonable. > 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 mode? -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Description: PGP signature