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

[Matthias Klose <doko@cs.tu-berlin.de>]

Joel Klecker writes:
 > Package: bash
 > Severity: critical
 > 
 > At 19:45 +0100 1999-11-20, Matthias Klose wrote:
 > >I have put together packages for bash-2.03 and readline-4.0. You find
 > >them at http://master.debian.org/~doko/bash-rl. Many bugs are fixed.
 > >Please see the changelogs. A still open issue is a working slink
 > >update.
 > 
 > There's a serious issue with /bin/sh that needs to be addressed. Some NMU
 > completely destroyed bash's Essential status[1] by handling the /bin/sh
 > symlink outside of dpkg's control. The /bin/sh crap needs to be removed
 > from the maintainer scripts and the binary package needs to contain the
 > /bin/sh symlink again. This is a critical bug.

What about the possibility that /bin/sh becomes an alternative, which
is provided by bash? Of course bash's postinst has to use /bin/bash.
But does bash's postinst runs before any other configure scripts run?

 > >Current status:
 > > - libreadlineg2 contains /etc/inputrc
 > > - bash-2.02 is statically linked to libreadlineg2
 > >
 > >Assume we do want to link bash dynamically against readline, history
 > >and ncurses.
 > 
 > Statically linking bash to readline was a stopgap to deal with
 > libreadline's ABI changing in a rather nasty way between glibc2.0 and
 > glibc2.1.
 > It was expected that potato would get libreadline4, after which bash could
 > be dynamically linked with readline again.

"it was expected": you don't expect it anymore?

Who decides? Currently I do have apackage, which fixes more than
critical and important bugs. Should it be uploaded, when all critical
bugs are resolved? Even if it's a new upstream version?

I hesitate uploading readline4. It seems that bash-2.04 (and another
readline) get's prepared for an upstream release, so it's  probably
better to skip the readline4 version at all and to link bash-2.03
statically.

 > >To avoid this for future libreadline updates, I would like to put
 > >/etc/inputrc into it's own package (are configuration files in library
 > >packages evil ;-?)
 > 
 > I think policy needs to explicitly forbid "configuration files" (whether
 > marked as conffiles or not) in library packages.

I'll move it to libreadline-base and make all libreadlines depend on it.