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

Re: new upstream Cogito conflicts with GNU Interactive Tools



On Thu, 2 Jun 2005, J. Bruce Fields wrote:

On Thu, Jun 02, 2005 at 05:24:47PM -0600, Bruce Sass wrote:
Isn't this simply a case of,`too bad cogito guys, that filename is
already taken.'

I suppose other things being equal it'd make sense to give the older
package priority.

Though git (the new one) seems something that users are particularly
likely to build (and distribute) rather complicated scripts on top of,
which may make the rename more annoying.

Maybe they deserve to be annoyed, too bad the users would bear the brunt of it though. :-/


What is this new /usr/bin/git?  It must be very new since on May 19th:

     * Move the git(1) manpage to git(7).  That's where it belongs (it doesnt
     correspond to a command), and there it won't conflict with the git(1)
     manpage from the git package (GNU Interactive Tools).  closes: #309776

     - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309776

I see mention in http://www.kernel.org/pub/software/scm/cogito/README
of commands like: git-checkout-cache, git-read-tree, git-cat-file... is SCM's git (?) an alternate ui for those commands, something new, ?

In the case that SCM's git is an alt ui:
How bad would it be if Debian didn't support it?

How bad would it be if the new git lived at /usr/lib/cogito/git (or perhaps some other, more appropriate, path). Packagers depending on cogito and using its git should be able to handle that easily, maybe even provide a script to do the translation for Debian's users grabbing 3rd party stuff which wants SCM's git.

How about having cogito and git detect the conflict and offer/prompt for a course of action (alias, mv, --remove, one or the other), with the appropriate defaults and priorities so debconf scripts do the right thing for most users.


- Bruce



Reply to: