FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-08-2008, 01:39 AM
Michael Tautschnig
 
Default Bug#482528: heimdal-clients,krb5-user

> Hello,
>
> Can I please have some input into this bug report?
>
> The report itself seems valid, ideally these packages shouldn't conflict.
>
> Solving this in such a way as not to break lots of stuff could be
> awkward though.
>
> Ideas?
>

Are you guys really sure that alternatives are so misplaced here?
- Both perform a similar function.
- A user installing any of the alternatives providing kadmin will probably know
what they are doing (at least so I guess); and (to be checked) using the wrong
one will do no harm to the Kerberos database, it will just not work.
- update-alternatives --list editor
/bin/ed
/bin/nano
/usr/bin/vim.tiny
/usr/bin/emacs21
/usr/bin/vim.basic

Same command line interface? Definitely not. Same functionality? They all
modify a piece of text, but that's about it. No need to flame, though, one
could probably give a lot more examples other than editor.

Best,
Michael
 
Old 07-08-2008, 02:19 AM
Russ Allbery
 
Default Bug#482528: heimdal-clients,krb5-user

Michael Tautschnig <mt@debian.org> writes:

>> Can I please have some input into this bug report?
>>
>> The report itself seems valid, ideally these packages shouldn't conflict.
>>
>> Solving this in such a way as not to break lots of stuff could be
>> awkward though.
>>
>> Ideas?

Adding alternatives for kinit, klist, kdestroy, and kpasswd is I think an
obvious move and I'm happy to help do that on the MIT Kerberos side.

Using alternatives for kadmin is more problematic.

(BTW, Brian, this discussion reminds me that I'd like to use alternatives
for krb5.conf.5 so that krb5-doc and heimdal-doc don't need to conflict.
I'd like to have krb5-config provide a stub with a low priority and
krb5-doc and heimdal-doc both provide versions with a higher priority.)

> Are you guys really sure that alternatives are so misplaced here?
> - Both perform a similar function.
> - A user installing any of the alternatives providing kadmin will
> probably know what they are doing (at least so I guess); and (to be
> checked) using the wrong one will do no harm to the Kerberos database,
> it will just not work.

Historically, debian-devel and discussions elsewhere have said that
alternatives is not appropriate in this case. The command line syntax is
completely different and the commands are completely different. Any
script that uses kadmin as an interface will break if the alternative
doesn't point to the version that it expects. That's a fairly serious
problem.

There are some differences in the syntax and flags of the other commands,
but it's more minor and won't affect most applications.

We can discuss it on debian-devel, though. If the rest of the project
blesses the idea of using alternatives, I'm okay with it, although I think
it has some potential to really confuse things. It would be easier if MIT
provided an exported API for kadmin, but since they don't, there are a
*lot* of scripts out there that use the kadmin client as an API.

> - update-alternatives --list editor
> /bin/ed
> /bin/nano
> /usr/bin/vim.tiny
> /usr/bin/emacs21
> /usr/bin/vim.basic

editor and pager are special exceptions to the normal alternative rules
and are specifically documented in Policy. Other programs have
historically not been allowed to use that sort of exception.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 08:02 AM
Bastian Blank
 
Default Bug#482528: heimdal-clients,krb5-user

On Mon, Jul 07, 2008 at 07:19:44PM -0700, Russ Allbery wrote:
> Using alternatives for kadmin is more problematic.

Which means that you need to find a consens and rename _both_ if none is
found.

> (BTW, Brian, this discussion reminds me that I'd like to use alternatives
> for krb5.conf.5 so that krb5-doc and heimdal-doc don't need to conflict.

Prdon, this is missuse of that mechanism. man already can do that.

Bastian

--
Wait! You have not been prepared!
-- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 01:08 PM
Sam Hartman
 
Default Bug#482528: heimdal-clients,krb5-user

Yeah, I'm reasonably sure that alternatives are wrong for kadmin.
Editor is intended to be used by a user. Kadmin is often used by
users but is also quite often used by scripts.

Editors also can all work with text files. It's basically not true
that you can use a heimdal kadmin against an MIT realm. I can think
of basically no situation where they are interchangable. However I
can think of many tasks where I'd be equally happy to use ed as Emacs.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 01:48 PM
Michael Tautschnig
 
Default Bug#482528: heimdal-clients,krb5-user

> Yeah, I'm reasonably sure that alternatives are wrong for kadmin.
> Editor is intended to be used by a user. Kadmin is often used by
> users but is also quite often used by scripts.
>
[...]

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

Any options that I'd be missing?

Best,
Michael
 
Old 07-08-2008, 04:50 PM
Russ Allbery
 
Default Bug#482528: heimdal-clients,krb5-user

Bastian Blank <waldi@debian.org> writes:
> On Mon, Jul 07, 2008 at 07:19:44PM -0700, Russ Allbery wrote:

>> Using alternatives for kadmin is more problematic.

> Which means that you need to find a consens and rename _both_ if none is
> found.

I certainly agree that's an even worse option.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 05:04 PM
Russ Allbery
 
Default Bug#482528: heimdal-clients,krb5-user

Michael Tautschnig <mt@debian.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-09-2008, 01:52 AM
Brian May
 
Default Bug#482528: heimdal-clients,krb5-user

Bastian Blank wrote:
>> (BTW, Brian, this discussion reminds me that I'd like to use alternatives
>> for krb5.conf.5 so that krb5-doc and heimdal-doc don't need to conflict.
>>
>
> Prdon, this is missuse of that mechanism. man already can do that.
>
How?

Brian May


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-09-2008, 06:28 AM
Russ Allbery
 
Default Bug#482528: heimdal-clients,krb5-user

Brian May <bam@snoopy.debian.net> writes:
> Bastian Blank wrote:

>>> (BTW, Brian, this discussion reminds me that I'd like to use alternatives
>>> for krb5.conf.5 so that krb5-doc and heimdal-doc don't need to conflict.

>> Prdon, this is missuse of that mechanism. man already can do that.

> How?

Alternatives expresses exactly the right semantics for this case.

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


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

Thread Tools




All times are GMT. The time now is 07:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org