Upload: bash-3.0-3 [test]

[Charles Wilson]

Igor Pechtchanski wrote:

> I would guess that bash itself won't need to do anything special -- it's a
> question of the alternatives package having reasonable defaults.  Whatever
> the case, whatever sets this up will need to run before other postinstall
> scripts.  It may even be worth it to get setup.exe to recognize and treat
> the alternatives postinstall/preremove scripts specially.

Nope, that's not how alternatives works.  It provides the facilities; 
individual packagers "hook in" to the system.  For instance, here's the 
postinstall script from automake1.9:

------------------begin----------------
#!/bin/sh
prefix=/usr
bindir=${prefix}/bin
sbindir=${prefix}/sbin

${sbindir}/update-alternatives \
   --install ${bindir}/automake automake ${bindir}/automake-1.9 50 \
   --slave   ${bindir}/aclocal  aclocal  ${bindir}/aclocal-1.9
------------------end----------------


and the pre-remove script from the same package:


------------------begin----------------
#!/bin/sh
prefix=/usr
bindir=${prefix}/bin
sbindir=${prefix}/sbin

${sbindir}/update-alternatives --remove automake ${bindir}/automake-1.9
------------------end----------------


Each of the other "alternativized" automake packages have similar 
scripts -- but with different "priorities" for the 'auto-prioritization' 
process.  (automake1.9 has priority 50; 1.8 == 40, ... 1.4p6 == 10).

The evolving process of these postinstall scripts being run creates the 
/var/lib/alternatives/automake file, which looks like this on my system:

------------------begin----------------
auto
/usr/bin/automake
aclocal
/usr/bin/aclocal

/usr/bin/automake-1.4
10
/usr/bin/aclocal-1.4
/usr/bin/automake-1.6
20
/usr/bin/aclocal-1.6
/usr/bin/automake-1.7
30
/usr/bin/aclocal-1.7
/usr/bin/automake-1.8
40
/usr/bin/aclocal-1.8
/usr/bin/automake-1.9
50
/usr/bin/aclocal-1.9
------------------end----------------


But the alternatives package does not itself install or provide this 
database entry.  It is *created* by the postinstall scripts of the 
alterntivized automake1.X packages themselves.

Thus (and let's pretend that symlinks are OK in this application, 
ignoring the whole binary-wrap issue), to use the alternatives 
framework, you'd do the following:

(1) the ash package would include commands similar to those above in its 
post-install/pre-remove scripts, with (for instance) a priority of 10.

(2) the bash package would do so as well, but with a higher priority.

(3) ditto the ksh package.

The 'auto' mode would ensure that the alternatives system keeps the 
symlinks set up to "activate" the highest-priority, currently-installed 
"alternative" within this set {sh, ash, ksh}.  If the end-user wants to 
make her own selection, she'd issue the appropriate 'update-alternatives 
--manual' command (or, personally change the links in /etc/alternatives; 
the system is smart enough to figure that out next time one of the 
post-install scripts is run, and change the database to manual).

Yes, this requires cooperation between the maintainers of alternativized 
packages -- AND an agreement as to which package will have the higher 
priority.  THAT's something that should be hashed out on this list, for 
any alternative-set.

--
Chuck