Debian Developers - shouldn't I use update-alternatives for this?

Author

shouldn't I use update-alternatives for this?

Sebastian Kuzminsky

2005-08-11, 3:13 am

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-po...#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-po...ternatives.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

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Thiemo Seufer

2005-08-11, 3:13 am

Sebastian Kuzminsky wrote:
> 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-po...#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?

No. Alternatives provide several implementations of similiar
functionality, and allow the user to select the preferred one.

Cogito and git provide _different_ functionality.

Thiemo

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Qingning Huo

2005-08-11, 7:51 am

On Wed, Aug 10, 2005 at 10:09:44PM -0600, Sebastian Kuzminsky wrote:
> 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

As I understand it, update-alternatives is used for programs providing
similar functions, this is not the case for /usr/bin/git.

Please consider Debian as a multiuser OS, what should the admin do if
half the user want git the scm, and the other half want GNU Interactive
Tools?

I suggest dpkg-divert /usr/bin/git, and install a shell script as
/usr/bin/git, which will invoke either program depending on a certain
environment variable[1] or a configuration file. It is possible to achieve
the following objectives.

(1) Installing cogito will not change the meaning of /usr/bin/git by
default;

(2) System admin can decide a default preference of /usr/bin/git,
through e.g. /etc/git.rc;

(3) Each user can choose her/his own preference by e.g. ~/.gitrc;

(4) cogito on Debian works the same as on other systems.

Of course, whatever configuration files or environment variables used
should be agreed by both package maintainers.

[1] I understand environment variable is not the recommended way to
configure Debian packages. However, it can be used as a shortcut to
avoid reading any configuration files.

Regards,
Qingning

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Marco d'Itri

2005-08-11, 5:55 pm

On Aug 11, Sebastian Kuzminsky <seb@highlab.com> wrote:

> 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?
Reality? git is the kernel SCM and GNU Interactive Tools is an obscure
package, and you should just install /usr/bin/git.
If the GNU Interactive Tools maintainer refuses to rename the other
program then just conflict with it.

--
ciao,
Marco

Petter Reinholdtsen

2005-08-11, 5:55 pm

[Marco d'Itri]
> Reality? git is the kernel SCM and GNU Interactive Tools is an
> obscure package, and you should just install /usr/bin/git.
> If the GNU Interactive Tools maintainer refuses to rename the other
> program then just conflict with it.

Ah, conflict resolution by the use of force. The method seem to gain
popularity in the world today, but I do not recommend it.

It is is not obvious which tool is more obscure, as this will differ
from user group to user group. It is a better idea for the
maintainers to try to reach an agreement, and perhaps to discuss the
choice of name with upstream as well, to try to make the choosen name
used in other distros.

Friendly,
--
Petter Reinholdtsen

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Sebastian Kuzminsky

2005-08-11, 5:55 pm

Petter Reinholdtsen <pere@hungry.com> wrote:
> [Marco d'Itri]
>
> Ah, conflict resolution by the use of force. The method seem to gain
> popularity in the world today, but I do not recommend it.
>
> It is is not obvious which tool is more obscure, as this will differ
> from user group to user group. It is a better idea for the
> maintainers to try to reach an agreement, and perhaps to discuss the
> choice of name with upstream as well, to try to make the choosen name
> used in other distros.

The "just conflict" idea is what I naively did first, and got flamed
right here on debian-devel. [1]

I've pushed the "rename it upstream" idea on the upstream maintainers
twice now and it gets shut down by both Linus (the original author)
and Junio (the current maintainer). [2]

update-alternatives seems like it would work but it's apparently not
supposed to used unless the programs that share a name also do the
same thing.

Qingning Huo suggested using diversions to make /usr/bin/git a little
selector script that lets the admin & user choose between git-the-shell
and git-the-scm. This sounds good to me, who objects?

[1]: http://lists.debian.org/debian-deve...6/msg00909.html

[2]: http://marc.theaimsgroup.com/?l=git...71729330066&w=2

--
Sebastian Kuzminsky

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Joey Hess

2005-08-11, 5:55 pm

Sebastian Kuzminsky wrote:
> 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.

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.

-- policy 10.1.

> 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

Yeah and people who want to deal with kernel sources would complicate
this scenario greatly. And then someone might package "rm" as "git" just
to prove the point. There's a reason we don't do this.

--
see shy jo

W. Borgert

2005-08-11, 5:55 pm

Quoting Sebastian Kuzminsky <seb@highlab.com>:
> I've pushed the "rename it upstream" idea on the upstream maintainers
> twice now and it gets shut down by both Linus (the original author)
> and Junio (the current maintainer). [2]

There is still the option to rename it for Debian only,
without changing it upstream. Not really nice, but
possible and used in the past, IIRC.

> Qingning Huo suggested using diversions to make /usr/bin/git a little
> selector script that lets the admin & user choose between git-the-shell
> and git-the-scm. This sounds good to me, who objects?

Aarrgghh! :-) That's what alternatives are for and people
already objected for good reasons. Please not.

Either rename the executable to /usr/bin/git-the-scm (or
whatever) or conflict with the other git. Or ask the
other git people to rename their binary. Maybe git-the-scm
is (or will be) in wider use than git-the-shell, so it
might be OK to rename the more "obscure" executable.

Cheers, WB

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Steinar H. Gunderson

2005-08-11, 5:55 pm

On Thu, Aug 11, 2005 at 09:20:23AM -0600, Sebastian Kuzminsky wrote:
> Qingning Huo suggested using diversions to make /usr/bin/git a little
> selector script that lets the admin & user choose between git-the-shell
> and git-the-scm. This sounds good to me, who objects?

What are you going to do about automated scripts that use either?

/* Steinar */
--
Homepage: http://www.sesse.net/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2005-08-11, 5:55 pm

Scripsit "W. Borgert" <debacle@debian.org>

> Either rename the executable to /usr/bin/git-the-scm (or
> whatever) or conflict with the other git.

Conflicting is Not An Option. So policy says, for good reasons.

> Or ask the other git people to rename their binary. Maybe
> git-the-scm is (or will be) in wider use than git-the-shell, so it
> might be OK to rename the more "obscure" executable.

There is precedence to consider. Sarge already contains a git package
that provides /usr/bin/git. Users who update from sarge to etch would
not be served well if the software they are used to suddenly changes
name just to accommodate a newcomer.

OTOH, cogito is not in sarge; there are no prior user expectations
about what its command name should be.

--
Henning Makholm "Punctuation, is? fun!"

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

W. Borgert

2005-08-11, 5:55 pm

Quoting Henning Makholm <henning@makholm.net>:
> Conflicting is Not An Option. So policy says, for good reasons.

OK, bad idea.

> There is precedence to consider. Sarge already contains a git package
> that provides /usr/bin/git. Users who update from sarge to etch would
> not be served well if the software they are used to suddenly changes
> name just to accommodate a newcomer.
>
> OTOH, cogito is not in sarge; there are no prior user expectations
> about what its command name should be.

Well, there will be user expectations (e.g. if people use cogito-git
on other distributions as well), but I agree: We can live with that.

Cheers, WB

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Brian Nelson

2005-08-11, 5:55 pm

On Thu, Aug 11, 2005 at 05:28:48PM +0200, Steinar H. Gunderson wrote:
> On Thu, Aug 11, 2005 at 09:20:23AM -0600, Sebastian Kuzminsky wrote:
>
> What are you going to do about automated scripts that use either?

Uhhh, why the hell would users of "GNU Interactive Tools" use them
non-interactively?

--
Society is never going to make any progress until we all learn to
pretend to like each other.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Sebastian Kuzminsky

2005-08-11, 8:49 pm

Qingning Huo <qingningh@lanware.co.uk> wrote:
> I suggest dpkg-divert /usr/bin/git, and install a shell script as
> /usr/bin/git, which will invoke either program depending on a certain
> environment variable[1] or a configuration file. It is possible to achieve
> the following objectives.
>
> (1) Installing cogito will not change the meaning of /usr/bin/git by
> default;
>
> (2) System admin can decide a default preference of /usr/bin/git,
> through e.g. /etc/git.rc;
>
> (3) Each user can choose her/his own preference by e.g. ~/.gitrc;
>
> (4) cogito on Debian works the same as on other systems.

This sounds like a great suggestion, thank you very much.

In this thought experiment, the cogito package would do this:

1. Install its git as /usr/bin/git.scm (or something).

2. Divert GNU Interactive Tools' /usr/bin/git to /usr/bin/git.shell
(or something).

3. Install something like this as /usr/bin/git (written in the
mailer, not tested):
#!/bin/sh
GIT=/usr/bin/git.scm
[ -f /etc/git-selector ] && source /etc/git-selector
[ -f $HOME/.git-selector ] && source $HOME/.git-selector
exec $GIT

4. Typical /etc/git-selector, set via debconf on install of cogito:
#GIT=/usr/bin/git.scm
GIT=/usr/bin/git.shell

5. Typical $HOME/.git-selector, set by user:
GIT=/usr/bin/git.scm
#GIT=/usr/bin/git.shell

Wow, this seems like a really nice save -- I especially like objective 4.

I changed the names git.rc and .gitrc, as those might reasonably be
taken by the upstream package(s).

Does this solution seem acceptable to everyone?

--
Sebastian Kuzminsky

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2005-08-11, 8:49 pm

Scripsit Sebastian Kuzminsky <seb@highlab.com>
> Qingning Huo <qingningh@lanware.co.uk> wrote:

[vbcol=seagreen]
> Does this solution seem acceptable to everyone?

No it doesn't. It has the same basic trouble as using alternatives.
The fact that it uses a granularity of accounts rather than a
granularity of machines for choosing between one program and the
other does not change the property that it requires such a spurious
choice to be made.

The choice is spurious because there is (as I understand it) nothing
inherent in the two pieces of software that makes it nonsensical for
someone to want to use both of them regularly. For this, each of them
needs to have a unique name.

Even if nobody ever wanted to use both, a solution that silently pulls
the carpet from under users that are used to git #1 just because the
sysadmin installs git #2 *and does not uninstall anything*, is not
desirable at all.

If the maintainers of the two packages cannot resolve the question of
name priority amicably, the matter will have to be referred to the
Technical Committee. There can be no circumventing this.

--=20
Henning Makholm "Jeg mener, at der eksisterer et hemmeligt
selskab med forgreninger i hele verden, som
arbejder i det skjulte for at udsprede det rygte at
der eksisterer en verdensomsp=E6ndende sammensv=E6rge=
lse."