Michael Tautschnig <[EMAIL PROTECTED]> writes:
> Well, if alternatives is the wrong approach, let's try an analytical approach:
>
> - heimdal-clients and krb5-user must not both be installed: Clearly,
> conflicts: is indicated. Then both may provide kadmin. It will break
> no system (they can't both get installed right now).
Bastian is arguing that this violates Policy 10.1:
Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via "alternatives" or the "Conflicts" mechanism. See Maintainer
Scripts, Section 3.9 and Conflicting binary packages - Conflicts,
Section 7.4 respectively.) If this case happens, one of the programs
must be renamed. The maintainers should report this to the
debian-devel mailing list and try to find a consensus about which
program will have to be renamed. If a consensus cannot be reached,
both programs must be renamed.
I think I disagree, but I'm not sure.
The crux of my disagreement is that I think the bar for using alternatives
is higher than the bar for using Conflicts. I think that kadmin provides
sufficiently similar functionality in both heimdal-clients and krb5-user
to not qualify as "different functionality" in Policy 10.1, since both
binaries fundamentally do the same thing (manage a Kerberos realm).
However, since the *API* is completely different, I don't think they
qualify for alternatives. Policy 3.9 says:
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. (In this case, it may be appropriate to specify a
conflict against earlier versions of something that previously did not
use update-alternatives; this is an exception to the usual rule that
versioned conflicts should be avoided.)
which is what we're complying with right now. I don't think this is
hair-splitting, but I could be wrong.
Policy doesn't provide any real guidance at the moment on when
alternatives are appropriate and when they aren't.
> - Conversely, the packages do not conflict. Then they must not both
> provide kadmin. I guess that there is consensus that even neither of
> them must ship kadmin.
> - If no kind of aliasing is provided, surely all scripts are going to break.
> It will force users to clean up their scripts. A migration path may be
> provided, but this will just delay breakage.
It will also break all scripts written for other systems that someone
tries to use on Debian.
> - If an alias is provided (be it alternatives or whatever), it will
> not cause scripts to break whenever the link points to the proper
> kadmin. Determined by luck or proper system administration. It will
> break fewer systems. Alternatives at least provide a clean
> interface to such a shared alias. They may be inappropriate, though,
> as pointed out.
Right.
The other option, just for the sake of completeness, is to have one
package win and the other lose and have to rename only its kadmin binary.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
