Re: ash vs. bash

[Julian Gilbey <J.D.Gilbey@qmw.ac.uk>]

> Julian Gilbey <J.D.Gilbey@qmw.ac.uk> wrote:
> > Read the code, realise how long there is and how many <do X> || die 
> > commands there are between deleting the old link and installing the
> > new one, and it will be obvious.  It's not a question of two links
> > rather than one, but a question of "what happens if
> > update-alternatives fails for some reason"?
> 
> Which is really sad because there's no reason for this.
> 
> Proper way to update the link is:
> 
> create new link under some unique name,
> rename new link so it occupies the old name.
> 
> [This will automatically delete the old link if it occupies
> the old name.]
> 
> I suppose I ought to file a bug report against update-alternatives,
> but I don't really have the time at the moment...

There are two links involved.  You have to synchronise them.  You have
to have proper unwinding.  And you have to cope with any potential
pre-existing mess.  It's non-trivial, but in most cases it seems to
work fine.  All I was saying was that it would not be wise to trust
such software for a system-critical link such as the /bin/sh link.
(And I wouldn't use a Perl script for arranging library links either.)

As a possible solution to the problem, bash could do something like
the following:

preinst:

if test -f /bin/sh; then
  cp -d /bin/sh /bin/sh.save
fi

postinst:

if test -f /bin/sh.save; then
  mv /bin/sh.save /bin/sh
fi

Then there is always a /bin/sh (except during the execution of the mv
command) and its nature is preserved, except for the short period
between the unpacking of the bash package and it being configured.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg