Re: new upstream Cogito conflicts with GNU Interactive Tools
I demand that Junichi Uekawa may or may not have written... [snip] My recommended action is: 1. tell them /usr/bin/git name is already taken, and we're renaming it to piggy I'd say sum, but that's already taken too. ;-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Those who in quarrels interpose must often wipe a bloody nose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
Hi, The upstream Cogito people have added a /usr/bin/git executable (over my objections) which conflicts with GNU Interactive Tools' /usr/bin/git. Their argument is that GNU Interactive Tools is obsoleted by mc and should just go away. Should I just make my cogito package Conflict with the GNU Interactive Tools git package? I don't think we really need /usr/bin/git. It's just a wrapper that runs /usr/bin/git-whatever-script My recommended action is: 1. tell them /usr/bin/git name is already taken, and we're renaming it to piggy alternatives is unintuitive, because we will see the problem of 'git' is this on one system, but is another on another system, and they are completely different things. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
Sebastian Kuzminsky wrote: The upstream Cogito people have added a /usr/bin/git executable (over my objections) which conflicts with GNU Interactive Tools' /usr/bin/git. Their argument is that GNU Interactive Tools is obsoleted by mc and should just go away. For what it's worth, popcon.debian.org says that 97 people (out of 6409 participating) have git installed, while only 63 have cogito installed. So if anyone loses that argument, it's cogito and not git :-) (It also appears that cogito isn't even in Sarge, so bear in mind that someone upgrading from Sarge to Etch may very well have git installed and then try to install cogito.) -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new upstream Cogito conflicts with GNU Interactive Tools
The upstream Cogito people have added a /usr/bin/git executable (over my objections) which conflicts with GNU Interactive Tools' /usr/bin/git. Their argument is that GNU Interactive Tools is obsoleted by mc and should just go away. Should I just make my cogito package Conflict with the GNU Interactive Tools git package? -- Sebastian Kuzminsky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
Le Jeudi 02 Juin 2005 21:25, Sebastian Kuzminsky a écrit : Should I just make my cogito package Conflict with the GNU Interactive Tools git package? I'm not sure if this a solution here, but their is a tool that can be usefull: update-alternatives. If your user has to use only one of both, then this can do the trick. Otherwhile, I can remenber the emule package having the same problems with the ed2k link parser located at /usr/bin/ed2k for for xmule and amule packages. Romain pgpS2ZxJH8OTX.pgp Description: PGP signature
Re: new upstream Cogito conflicts with GNU Interactive Tools
On Thu, 02 Jun 2005, Romain Beauxis wrote: Le Jeudi 02 Juin 2005 21:25, Sebastian Kuzminsky a écrit : Should I just make my cogito package Conflict with the GNU Interactive Tools git package? I'm not sure if this a solution here, but their is a tool that can be usefull: update-alternatives. If your user has to use only one of both, then this can do the trick. Otherwhile, I can remenber the emule package having the same problems with the ed2k link parser located at /usr/bin/ed2k for for xmule and amule packages. Please do not suggest using the alternatives system this way. The alternatives system is there for situations as above - when two programs provide a similar or indistinguishable service, such as a window-manager or ed2k parser. cogito and GNU Interactive Tools provide remarkedly different functions. My suggestion is to rename the binary in the cogito package to something which makes more sense, perhaps cogito-git. -- Michael Janssen --- Jamuraa --- [EMAIL PROTECTED] --- [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
On Thu, Jun 02, 2005 at 04:51:12PM -0500, Michael Janssen wrote: Le Jeudi 02 Juin 2005 21:25, Sebastian Kuzminsky a écrit : Should I just make my cogito package Conflict with the GNU Interactive Tools git package? ... My suggestion is to rename the binary in the cogito package to something which makes more sense, perhaps cogito-git. Why not just take the git developers at their word, and assume that the intersection between users of git and of GNU Interactive Tools is likely to be the empty set? Then you can just make them conflict, and don't bother with any workarounds until you actually find someone who cares about both --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
On Thu, 02 Jun 2005, J. Bruce Fields wrote: On Thu, Jun 02, 2005 at 04:51:12PM -0500, Michael Janssen wrote: Le Jeudi 02 Juin 2005 21:25, Sebastian Kuzminsky a écrit : Should I just make my cogito package Conflict with the GNU Interactive Tools git package? ... My suggestion is to rename the binary in the cogito package to something which makes more sense, perhaps cogito-git. Why not just take the git developers at their word, and assume that the intersection between users of git and of GNU Interactive Tools is likely to be the empty set? Then you can just make them conflict, and don't bother with any workarounds until you actually find someone who cares about both Because Debian Policy forbids this in section 10.1: ''' Two different packages must not install programs with different functionality but with the same filenames. If this case happens, one of the programs must be renamed. ''' Either rename one of the programs or (if it is actually true that noone uses GNU Interactive Tools) have git removed from the archive. -- Michael Janssen --- Jamuraa --- [EMAIL PROTECTED] --- [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
On Thu, Jun 02, 2005 at 06:05:53PM -0500, Michael Janssen wrote: On Thu, 02 Jun 2005, J. Bruce Fields wrote: Why not just take the git developers at their word, and assume that the intersection between users of git and of GNU Interactive Tools is likely to be the empty set? Then you can just make them conflict, and don't bother with any workarounds until you actually find someone who cares about both Because Debian Policy forbids this in section 10.1: ''' Two different packages must not install programs with different functionality but with the same filenames. If this case happens, one of the programs must be renamed. ''' Either rename one of the programs or (if it is actually true that noone uses GNU Interactive Tools) have git removed from the archive. Bah, yeah, OK.--b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new upstream Cogito conflicts with GNU Interactive Tools
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. --b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
