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

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

On Sat, Nov 20, 1999 at 07:45:38PM +0100, Matthias Klose wrote:
 
> - bash-2.03 should be part of potato.
> - should readline4 be part of potato? If no, then bash-2.03 can
>   statically linked with the included readline.

I would say yes.

> I never got any feedback from the package maintainer; who can decide
> to upload a new upstream version, if the maintainer shows no reaction?

My offer to take the package still stands. But I did not get any response 
from Guy. I don't want to try a hostile take over like Vodafone tries 
with Mannesmann ;)

> When doing a dist-upgrade from slink, libreadlineg2 with inputrc is
> first removed, then libreadline4 with inputrc is installed followed by
> the installation of libreadlineg2 without inputrc.
> 
> The problem is, that bash is somewhere installed in between and cannot 
> find the old libreadlineg2 found in slink.

In fact bash is even removed before removing libreadline2g since bash 
depends on it...

> What I would like to know: Is there a way of transferring ownership of 
> the /etc/inputrc file to another package without having the conflict to 
> libreadlineg2 (or: without having libreadlineg2 temporarly removed)?
> Or: How can I transfer ownership of a versioned library package to the 
> next version of the library?
> 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 ;-?)

May I suggest just leaving that file out? I think there are other config 
files which are not in any package but created by the user if needed. 
If man bash documents the place where we seek for inputrc and the info file 
does that too we can just remove /etc/inputrc from any package.

We could make an inputrc.default and put it into the doc dir stating the 
default values. In case the upstream defaults do not suit us we can change 
the code.

One problem remains - what if the local admin changed /etc/inputrc to be 
totally different? It would be removed on upgrade...

I see it now - we need libreadline-common :(

> Torsten Landschoff suggested using for libreadline4 a Replaces
> libreadlineg2 (<< version-with-inputrc). 
> 
> Reading the packaging manual, I see that Replaces should be
> sufficient, but if libreadline is purged at the same step, then
> /etc/inputrc is removed.

That can't happen. 

1. libreadline will not be purged without the user requesting this. If
somebody wants to purge a package he will now he loses the config files.
2. as soon as the new libreadline4 is installed ownership of the inputrc 
moves to that package and will stay there until we replace the file from 
another package.

I think this would be a clean transition.

> Any suggestions how to make the upgrade safe besides linking bash
> statically?

Let's see - assuming one tries to upgrade from slink to potato, here are 
the relevant dependencies:

slink:

    bash:       
        Pre-Depends:    libreadlineg2 (>= 2.1-8), libncurses4
    libreadlineg2:
        Depends:        libncurses4
        Conflicts:      libreadline2 (<< 2.1-2.1)

potato:

    bash (2.03): 
        Pre-Depends:    libreadlineg2 (??), libncurses4 (>= 4.2.xx), 
                        libreadline4 (>= 4.0)
    libreadlineg2:
        Depends:        libreadline4, libncurses4 (>= 4.2.xx)
        Conflicts:      libreadline2 (<< 2.1-2.1), bash (<< 2.02.1-1.2)

    libreadline4:
        Depends:        libncurses4 (>= 4.2.xx)
        Conflicts:      libreadlineg2 (<< 2.1-13.7)

Okay. Now think about installing this bash on slink:

Try to install: bash
-> need libreadlineg2 (already there from slink)
-> need libncurses4 (should be no problem and will get installed)
-> need libreadline4
  => Try to install: libreadline4
    -> need libncurses4 (no problem)
    -> conflict with libreadlineg2 installed from slink
      => can't remove libreadlineg2 needed by bash
      => try to upgrade libreadlineg2
        -> libreadlineg2 from potato conflicts with bash from slink
        *** UNRESOLVABLE ***

Solutions:
- link bash statically with libreadline4 (bad)
- remove conflict from current libreadlineg2 with bash from slink
  (would break bash, forget it)
- remove Conflict of libreadline4 with libreadlineg2 (which is bad anyway)
  using appropriate replaces

I will try that last approach out and mail the result of an apt install...

Thanks
    Torsten