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

shouldn't I use update-alternatives for this?



Yet another thread about cogito-vs-git, sorry folks.  Just killfile me
if I've worn out your patience.


Still there?  Great!


Background: I'm the guy who maintains the cogito package.  I had a problem
a while back because my upstream package wanted to install a program with
the same name as a program installed by GNU Interactive Tools (git.deb).
I asked on this list and was told that Conflicting with GNU Interactive
Tools was wrong, I should rename my upstream's program to avoid the
collision.  I didn't like this suggestion, but I complied with it.


Now, after bumbling around the Debian developer docs a little more,
I found this.  Section 3.10 of the Policy Manual states:

    <http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscripts>

    All packages which supply an instance of a common command name (or, in
    general, filename) should generally use update-alternatives, so that
    they may be installed together. If update-alternatives is not used,
    then each package must use Conflicts to ensure that other packages
    are de-installed.


Seems like a match to me.  git.deb and cogito.deb both supply an
instance of a common command name (/usr/bin/git).  So shouldn't I use
update-alternatives?


The only other mention I found of update-alternatives was in Appendix
F of the Policy Manual, here:

    <http://www.debian.org/doc/debian-policy/ap-pkg-alternatives.html>

Appendix F is marked as being "from old Packaging Manual".  The wording
here suggests that in order to use update-alternatives, the alternatives
need to "do the same thing" (like nvi and vim, for example).  This seems
to be in mild conflict with section 3.10: 3.10 talks about filename
conflicts without mentioning "interfaces" (which I take to mean the
"purpose" of the program or file).


So, I'm proposing this:

    GNU Interactive Tools installs /usr/bin/git.shell (or something)

    Cogito installs /usr/bin/git.scm (or something)

    update-alternatives is used to make one of those appear as
    /usr/bin/git


The same thing could be done for /usr/bin/cg, which is a name used by
cogito's upstream and the cgvg.deb package.


People who just want GNU Interactive Tools get what they want.  People who
just want Cogito get what they want.  People who want both have to learn
a new name for one of them.  Seems good to me.  Am I missing anything?


Calling Ian Beckwith (git maintainer) and Sergio Talens-Oliag (cgvg
maintainer): what do you think of this proposal?


-- 
Sebastian Kuzminsky



Reply to: