Re: experimental bash-2.03 and readline-4.0 packages for potato

[Torsten Landschoff <t.landschoff@gmx.net>]

On Sun, Nov 21, 1999 at 09:48:45AM -0500, Raul Miller wrote:
 
> Well, let's consider the cases you'd want to deal with:
> 
> (1) installing bash using dpkg -i --root

Hmm - I never though about this one. How can I check for it in the
installation scripts? I will consult the developers reference. It 
should work the same as dpkg -i on the target directory thus see 
below.

> (2) installing bash using dpkg --unpack

That's a tricky question :) What do you use --unpack for? Does apt 
use it?

My idea of this would be that the package itself should have the /bin/sh 
link so that you can run dpkg --unpack to get your system back under 
control. But this is debatable...

> (3) installing bash using dpkg -i

My idea of this would be as follows: 

- preinst: 
    Checks, if /bin/sh works by running a very simple script
    (or should we do a full regression test)?
  
    If it works, /bin/sh should be preserved my making it a divertion 
    or something like that which will be undone in the postinst. 

- unpack: 
    Installs default /bin/sh link and the full bash package of course.

- postinst: 
    Points /bin/sh back to the original location it was at preinst time 
    in case that shell worked okay. Otherwise just does nothing.

So what is the clean way to do this? 

Also I am not quite sure how apt does install packages. Could be that 
apt unpacks them, then runs the preinst and postinst? But that sounds 
plain wrong since preinst should be run before installation!?

> (A) installing bash on a working system with
> 	/bin/sh -> bash

Don't touch /bin/sh

> (B) installing bash on a working system with
>         /bin/sh -> [something else]

Leave /bin/sh alone if it works okay. Check by running this shell with 
something like "sh -c exit 0"  and checking the return code.

> (C) installing bash on a working system with
> 	/bin/sh -> /etc/alternatives/sh -> /bin/bash

I don't think we ever used alternatives to handle /bin/sh and this is how 
it should stay. update-alternatives did not work far to often for me to 
trust this system. The script even ignores links if they point to the void 
which is bad for /bin/sh me thinks.

> (D) installing bash on a working system with
> 	/bin/sh -> /etc/alternatives/sh -> [something else]

Same as (C).

> Frankly, I'm not sure what bash *should* do in all these cases.  
> 
> If you can tell me what bash should be doing for each of these
> cases I can tell you how to write the scripts.

I am not sure if there is consensus on this. Let's wait if there are any 
objections to this proposal and then think about implementing this scripts.

Thanks for you help!
    Torsten

PS: Should I retain the Cc to Joel? I am not sure if he is interested 
in this discussion - he has enough work with libc I think :)