RFC: update-alternatives

[Charles Wilson]

It seems there may be a need for a Debian-like update-alternatives 
system on cygwin (see the recent thread on the main list about making 
/bin/sh be bash instead of ash).  Also, such a system would be a better 
approach than my cobbled-together postinstall scripts for the many new 
versions of automake (ditto libpng).

I figure that something like update-alternatives should probably go into 
the Base category, since it might be used to swap the main system shell.

So, after a bit of looking around, I found several implementations

(1) Debian
   + the original
   + huge user base, well tested
   - uses perl

We really don't want perl in the Base category, do we?  If we use this 
one, then no package in Base may be allowed to "participate" in the 
alternatives system for fear of dragging perl as an unwanted dependence 
of the Base package.  Especially /bin/sh.

(2) Red Hat (Fedora 4)
   + complete rewrite in C, no perl dependency
   + work-a-like to original Debian version
   - as is, requires libintl and libiconv which are not in Base
   + fairly well tested, definitely widely installed but I'm not
     sure how pervasive it is actually USED within Fedora.
   - packaged inside Fedora's chkconfig

So, this must be disentangled from chkconfig (or I need to prevail upon 
the current chkconfig maintainer to switch to Fedora's version, and 
include/support update-alternatives: Sergey, you still around?). 
Further, we need to decide either to add gettext/iconv (or at least, 
libintl3 and libiconv2) to Base -- or remove internationalization 
support from alternatives.c.  Further, if instead of ME packaging 
update-alternatives separately, Sergey is convinced to switch his 
chkconfig over to Fedora's version -- Fedora's chkconfig is written in C 
as well and ALSO requires intl (more surgery, or another argument for 
bringing in intl into Base).

(3) ALT Linux's version
   + http://alternatives.sourceforge.net/ total rewrite
     using only sh, awk, and sed
   + requires no "new" packages to be added to Base
   - not NEARLY as widely tested as the others
   - some semantic differences in the implementation mean that
     its on-disk layout, script structure, AND usage is somewhat
     different than the other two.  May confuse people with extensive
     Linux experience other-than-ALTLinux.

Comments and suggestions requested -- especially from Sergey Okhapkin if 
he's still here.

--
Chuck