On Sun, Jul 30, 2006 at 07:27:03AM +0100, MJ Ray wrote: > Christian Aichinger <[EMAIL PROTECTED]> wrote: > > I think that reasoning is flawed. gitfm offers a different > > functionality as git-scm. [...] > > gitfm should not be registered as the alternative.
*sigh* I know. Sorry for not expressing it clear enough. I still think git.transition offers a different interface then git-scm. 'Interface' isn't just what other programs get to see of /usr/bin/git, but also what the user gets to see when he runs it manually. What if you have a shell script that calls git-scm as /usr/bin/git but doesn't redirect output in any way? That's not so uncommon, but will break as soon as git is installed on the system. > Also, if it's the best possible solution for a > namespace collision/transition, maybe policy or dev-ref ought > to be updated to include it explicitly? Well, policy would need an update for that. I'm not sure about the pros and cons though. While it's a decent way to transition a binary from one package to another, a nice point about the (current) alternatives system is that there's a common interface, no matter what alternative you choose (e.g. x-terminal-emulator -e always works). I'd be interested what others think about this.. > I'd downgrade to minor, on the basis that it doesn't affect > the package's usefulness and is trivial to fix as needed, > and tag it wontfix for now, adding fixed-upstream and pending > when they become appropriate. Up to the main maintainer, IMO. Well, we're discussing a (possible) policy violation here, minor seems a bit low for that (my favorites are etch-ignore or severity important). However since it's only temporary anyway, if the submitter is ok with it, who am I to complain.. Cheers, Christian Aichinger
signature.asc
Description: Digital signature
