Bug 692606

The kadmin init script would have to point to the non-alternatives location, but before we get that far, there's the problem that different implementations of these tools use disjoint command-line options.  How does this avoid breaking scripts and user expectations as soon as people toggle the alternative?

I think we're going to have to trust that people installing heimdal know what they are doing.  What other choice do we have?

Since we are just starting out with Heimdal, I was picturing that we would have MIT have the higher priority in the alternatives list. In order to break their system, a user would need to either uninstall MIT, or else manually manually run "alternatives" to override the priority. At that point it is the user's responsibility to verify that this will not break their own user-written code.

We could also decide to not use alternatives, and put the binaries elsewhere (either adding $PATH munging or requiring people to use full paths) or with different names (though as that's not what upstream names things, I'm not really keen on that).

We've got packages (parts of IPA, at least) that call utilities with specific flags, and I'm not in favor of using alternatives if it helps people inadvertently break things.

As I understand it, not putting the binaries in /usr/bin requires a FESCO exception.  We asked and were denied: https://fedorahosted.org/fesco/ticket/577.  Comment there if you'd like.

I added a note in favor of an exception being made.  After looking at the rsh implementation, I'm now convinced that you'll need one.

(In reply to comment #4)
> We could also decide to not use alternatives, and put the binaries elsewhere
> (either adding $PATH munging

Right now, krb5-appl-clients.sh sets /usr/kerberos/bin at the front of $PATH. To do this on the Heimdal side, we'd have to do the opposite and put it at the end of $PATH. Otherwise, we'd end up overriding MIT's /usr/bin/kinit, for example.

Secondarily, if we manipulate $PATH in /etc/profile.d, we'd have to be sure that "h" in "heimdal.sh" comes before "k" in "kerberos.sh", so we don't accidentally set $PATH in front of MIT.

I think alternatives would be a more flexible solution to have the two packages live peacefully. What do you think?

> or requiring people to use full paths)

Requiring full paths is not really the best option from a usability perspective, and alternatives would be able to save our users' typing.

> or with
> different names (though as that's not what upstream names things, I'm not
> really keen on that).

> We've got packages (parts of IPA, at least) that call utilities with specific
> flags,

Some of the flags (eg. -t for /path/to/keytab) are the same, but you're correct; there will be some differences. (Would you be able to use full paths in IPA?)

> and I'm not in favor of using alternatives if it helps people
> inadvertently break things.

If we kept the MIT alternatives priority higher that Heimdal, people would have to intentionally override that.

This could be similar to Java. If you've manually overridden your Java alternatives settings to use Oracle's JRE, then it's your own fault if Java apps are broken :)

(In reply to comment #7)
> Right now, krb5-appl-clients.sh sets /usr/kerberos/bin at the front of $PATH.
> To do this on the Heimdal side, we'd have to do the opposite and put it at the
> end of $PATH. Otherwise, we'd end up overriding MIT's /usr/bin/kinit, for
> example.
> 
> Secondarily, if we manipulate $PATH in /etc/profile.d, we'd have to be sure
> that "h" in "heimdal.sh" comes before "k" in "kerberos.sh", so we don't
> accidentally set $PATH in front of MIT.

How is there an ordering requirement between two scripts when one prepends to the path and the other appends?

> I think alternatives would be a more flexible solution to have the two packages
> live peacefully. What do you think?

It doesn't solve the things-breaking problem, so I'm not in favor.

> > We've got packages (parts of IPA, at least) that call utilities with specific
> > flags,
> 
> Some of the flags (eg. -t for /path/to/keytab) are the same, but you're
> correct; there will be some differences. (Would you be able to use full paths
> in IPA?)

IPA was an example, but there's no guarantee that it's the only case.

Hey can I vote for this one lol?
for the most part in my experience my experience most applications that make library calls will be fine as long as the MIT Kerberos libraries are intact.
The only thing that may potentially break are certain poorly written apps that make system calls which seem to be rare with kerberized applications, and compiles of certain software but for the most part the developers of Heimdal have gone to great lengths to make the two compatible.
I also agree with the statement the allowing the user to override with the alternatives option is no different then how java is currently handled.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.