[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, Nov 21, 1999 at 04:02:37PM +0100, Torsten Landschoff wrote:
> > (2) installing bash using dpkg --unpack
> 
> That's a tricky question :) What do you use --unpack for? Does apt 
> use it?

It's the general case.  Remember that if some other package fails
to install you'll be left in the unpack state.

> 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)?

simple is good.

>     If it works, /bin/sh should be preserved my making it a divertion 
>     or something like that which will be undone in the postinst. 

You mean you're diverting yourself, right?

> - 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? 

dpkg-divert --package bash --divert /bin/sh.installing-bash /bin/sh

I think dpkg does the right thing with this if you're installing
using dpkg --root, and you've got at least what's in the base
disks installed at that root, but it's worth testing.  I've not
played with --root myself, I've just encountered other people who
try to use it.

> > (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.

Which leads into what I was saying two messages back: if we're going
to use alternatives with bash they'll have to be re-engineered.

> 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 :)

Probably not, I've removed him from the cc list.

-- 
Raul


Reply to: