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: