This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Upload: bash-3.0-3 [test]
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