On Thu, 2007-03-08 at 13:32 -0500, Chip Coldwell wrote: > The "alternatives" stuff would by handled by the rpm %post script, so > users wouldn't have to know about it. Whichever of the two packages > you installed last becomes the default (assuming they don't conflict > as Jesse requested). That seems reasonable to me, but I'm interested > in learning what the standard practice for Fedora is. Hmm... which program is run when a user types a command being tied to (arbitrary) package installation order does not seem reasonable to me because of the high astonishment factor. I personally dislike hidden obscure changes to my system. Things suddenly work vastly differently because something occurred on my system I might not have any awareness of or ability to correlate to a specific change. I can easily imagine a scenario where someone does an install, they may not be aware it pulled in one of the emacs packages, or they might have done the install a few days earlier, or someone else might have done the install and now for no apparent reason from their perspective emacs stops working. Arghh!!! They might spend considerable time tracking it down and discover it's all due to convoluted symbolic link munging courtesy of alternatives. They probably never heard of alternatives, or even if they know of it would not consider this as the first place to look when their editor mysteriously stops working. Silently breaking previously working functionality is not a good design choice IMHO. I think the right behavior is if emacs-nox is installed on a system without X then the command 'emacs' invokes emacs-nox. If emacs with X support is installed the command 'emacs' invokes the X capable version (makes sense because that version of emacs can operate in either mode, it is obviously the preferred version). The alternatives system could be used to implement this because it does address the issue of RPM conflicts, but it would never be "last install wins", rather it would be "most capable wins" in %post. This has the least astonishment factor, satisfies the majority of use cases, and still allows switching if an advanced user is savvy enough to want to do that (but there really wouldn't be any reason to use alternative switching, the use of alternatives in this case is almost entirely to avoid RPM conflicts, not select vastly different implementations of a command e.g. sendmail vs. postfix, etc.) -- John Dennis <jdennis@xxxxxxxxxx> Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
