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

When to use update-alteratives



Sebastian Kuzminsky <seb@highlab.com> writes in a debian-devel thread:

> 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).

I believe that the statement that alternatives are supposed to be used for
commands that do roughly the same thing should be normative, and I'd
rather not see normative requirements in an appendix (plus, the appendices
aren't necessarily normative, as noted in Section 1.1).

Therefore, I think it would be good to add a statement like:

    update-alternatives must only be used to manage multiple
    implementations of a common command that all do roughly the same
    thing, and must not be used if the conflicting commands do completely
    different things.

That may be too verbose.  There's some fuzziness in "roughly" and
"completely" that probably can't be pinned down more than that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



Reply to: