Bug#848168: readline: Please drop the multilib packages

[Matthias Klose]

On 17.02.2018 16:32, Sven Joachim wrote:
> On 2018-02-17 09:33 +0700, Matthias Klose wrote:
> 
>> On 17.02.2018 03:06, Sven Joachim wrote:
>>> On 2016-12-15 21:28 +0100, Sven Joachim wrote:
>>>
 Which use case of foreign architecture dependencies is handled by the
 existing readline multilib packages?
>>>
>>> I still have not received an answer to this question, could you please
>>> elaborate?
>>
>> it's still the same reason as before: to build a 64bit gdb on 32bit
>> architectures.  Yes, I know that the gdb maintainer has removed the 64bit gdb
>> package unfortunately,
> 
> To which you did not really object, BTW.

was this announced somewhere outside the gdb packaging? In that case I might
have missed it.  And even then, I'm not a gdb packager.

> At least I did not understand
> "Did we stop building gdb64 packages for 32bit architectures?" in that
> sense.

> The original proposal in #775948, making gdb multiarch-coinstallable,
> might still make sense.  OTOH, on i386 installing gdb:amd64 is already
> possible, and for other architectures there is also gdb-multiarch.

No, I don't think that gdb-multiarch was covering all cases that gdb64 did.

>> but why make it even more difficult to build such a binary?
> 
> The reasons why I filed #848163, and the great complexity in the ncurses
> packaging due to multilib.  I know this is no problem for a guru like
> you who likes complicated packages, but I am a mere mortal with limited
> skills. :-(

well, even libtinfo had to be brought to you :-/

> Is there any problem building a 64-bit gdb on i386 after installing
> libreadline-dev:amd64, libncurses5-dev:amd64 and possibly other useful
> packages to give gdb more bells and whistles - the gdb64 package was
> equivalent to gdb-minimal?

this is only possible if both architectures are part of the release pocket, or
if you have matching versions of all packages in unstable. So at some times you
can do that in unstable, but you'll never be able to do that for release/testing
if one of these architectures is not part of the release.

Matthias

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

On 2018-02-17 09:33 +0700, Matthias Klose wrote:

> On 17.02.2018 03:06, Sven Joachim wrote:
>> On 2016-12-15 21:28 +0100, Sven Joachim wrote:
>> 
>>> Which use case of foreign architecture dependencies is handled by the
>>> existing readline multilib packages?
>> 
>> I still have not received an answer to this question, could you please
>> elaborate?
>
> it's still the same reason as before: to build a 64bit gdb on 32bit
> architectures.  Yes, I know that the gdb maintainer has removed the 64bit gdb
> package unfortunately,

To which you did not really object, BTW.  At least I did not understand
"Did we stop building gdb64 packages for 32bit architectures?" in that
sense.

The original proposal in #775948, making gdb multiarch-coinstallable,
might still make sense.  OTOH, on i386 installing gdb:amd64 is already
possible, and for other architectures there is also gdb-multiarch.

> but why make it even more difficult to build such a binary?

The reasons why I filed #848163, and the great complexity in the ncurses
packaging due to multilib.  I know this is no problem for a guru like
you who likes complicated packages, but I am a mere mortal with limited
skills. :-(

Is there any problem building a 64-bit gdb on i386 after installing
libreadline-dev:amd64, libncurses5-dev:amd64 and possibly other useful
packages to give gdb more bells and whistles - the gdb64 package was
equivalent to gdb-minimal?

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Matthias Klose]

On 17.02.2018 03:06, Sven Joachim wrote:
> On 2016-12-15 21:28 +0100, Sven Joachim wrote:
> 
>> Which use case of foreign architecture dependencies is handled by the
>> existing readline multilib packages?
> 
> I still have not received an answer to this question, could you please
> elaborate?

it's still the same reason as before: to build a 64bit gdb on 32bit
architectures.  Yes, I know that the gdb maintainer has removed the 64bit gdb
package unfortunately, but why make it even more difficult to build such a
binary?  The gdb upstream sources come with readline sources, but not with
ncurses sources, so you definitely make it harder to build this.

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

On 2016-12-15 21:28 +0100, Sven Joachim wrote:

> Which use case of foreign architecture dependencies is handled by the
> existing readline multilib packages?

I still have not received an answer to this question, could you please
elaborate?

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

On 2018-02-10 18:44 +0100, Matthias Klose wrote:

> that's not how cross builds are supposed to work. build with dpkg-buildpackage
> -a . of course fixing / removing the libc6-i386 b-d.  And no, you 
> can't
> upload such a package to the archive. Everything with dependencies on foreign
> archs gets rejected.

Oh, I had not realized that you were talking about cross builds, sorry.

> In the end we want to get away with multilibs, but it's
> too early to remove that multilib support.

I agree that gcc-multilib will have to be kept for some time, but I
still fail to see the use case for the readline multilib packages.

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Matthias Klose]

On 10.02.2018 18:09, Sven Joachim wrote:
> On 2018-02-10 15:00 +0100, Matthias Klose wrote:
> 
>> On 10.02.2018 13:41, Sven Joachim wrote:
>>>
>>> Also, while installing foreign architecture packages might sometimes be
>>> useful, linking a program in a newly built package against a shared
>>> foreign-arch library is not really possible, because dpkg-shlipdeps will
>>> generate incorrect dependencies for it.
>>
>> well, this is an issue which should be filed against dpkg-shlipdeps. Did you
>> actually try to build that?
> 
> Here's an example which you should be able to reproduce.  The
> grub-legacy package depends on multilib packages on amd64, since it's
> 32-bit only:
> 
> ,
> | $ apt-cache show grub-legacy:amd64 | grep Depends
> | Depends: lib32ncurses5 (>= 6), lib32tinfo5 (>= 6), libc6-i386 (>= 2.7), 
> grub-common
> `
> 
> Let's try to build it with i386 packages instead of multilib:
> 
> ,
> | $ apt-get source grub
> | $ sed -i '/lib32ncurses5-dev/libncurses5-dev:i386/' grub-0.97/debian/control
> `
> 
> Build the package in a chroot with amd64 as native and i386 as foreign
> architecture, I used pbuilder for that.  This is the result:
> 
> ,
> | $ dpkg-deb -f grub-legacy_0.97-72_amd64.deb | grep Depends
> | Depends: libc6 (>= 2.7), libncurses5 (>= 6), libtinfo5 (>= 6), grub-common
> `
> 
> The problem here is that the dependencies are not arch-qualified.

that's not how cross builds are supposed to work. build with dpkg-buildpackage
-a . of course fixing / removing the libc6-i386 b-d.  And no, you can't
upload such a package to the archive. Everything with dependencies on foreign
archs gets rejected.  In the end we want to get away with multilibs, but it's
too early to remove that multilib support.

Matthias

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

On 2018-02-10 15:00 +0100, Matthias Klose wrote:

> On 10.02.2018 13:41, Sven Joachim wrote:
>> 
>> Also, while installing foreign architecture packages might sometimes be
>> useful, linking a program in a newly built package against a shared
>> foreign-arch library is not really possible, because dpkg-shlipdeps will
>> generate incorrect dependencies for it.
>
> well, this is an issue which should be filed against dpkg-shlipdeps. Did you
> actually try to build that?

Here's an example which you should be able to reproduce.  The
grub-legacy package depends on multilib packages on amd64, since it's
32-bit only:

,
| $ apt-cache show grub-legacy:amd64 | grep Depends
| Depends: lib32ncurses5 (>= 6), lib32tinfo5 (>= 6), libc6-i386 (>= 2.7), 
grub-common
`

Let's try to build it with i386 packages instead of multilib:

,
| $ apt-get source grub
| $ sed -i '/lib32ncurses5-dev/libncurses5-dev:i386/' grub-0.97/debian/control
`

Build the package in a chroot with amd64 as native and i386 as foreign
architecture, I used pbuilder for that.  This is the result:

,
| $ dpkg-deb -f grub-legacy_0.97-72_amd64.deb | grep Depends
| Depends: libc6 (>= 2.7), libncurses5 (>= 6), libtinfo5 (>= 6), grub-common
`

The problem here is that the dependencies are not arch-qualified.

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Matthias Klose]

On 10.02.2018 13:41, Sven Joachim wrote:
> Control: tags -1 + patch
> 
> On 2016-12-15 21:28 +0100, Sven Joachim wrote:
> 
>> On 2016-12-15 08:38 +0100, Matthias Klose wrote:
>>
>>> On 14.12.2016 21:05, Sven Joachim wrote:
 Source: readline
 Version: 7.0-1
 Tags: buster sid
 Control: block 848163 by -1

 I intend to remove the ncurses multilib packages after the stretch
 release, see #848163.  Since ncurses is required to build readline, this
 means that the readline multilib packages can then no longer be built.

 There are no reverse dependencies of the readline multilib packages, so
 removing them should not be a problem.
>>>
>>> Did we stop building gdb64 packages for 32bit architectures?
>>
>> Yes, since gdb 7.9-1.
>>
>>> I'd like to delay that change until the buildds can manage dependencies on
>>> foreign architectures.
>>
>> Has there been any progress on that?  Bug #770925 has not seen any
>> updates for 16 months. :-(
>>
>> Which use case of foreign architecture dependencies is handled by the
>> existing readline multilib packages?
> 
> Also, while installing foreign architecture packages might sometimes be
> useful, linking a program in a newly built package against a shared
> foreign-arch library is not really possible, because dpkg-shlipdeps will
> generate incorrect dependencies for it.

well, this is an issue which should be filed against dpkg-shlipdeps. Did you
actually try to build that?

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

Control: tags -1 + patch

On 2016-12-15 21:28 +0100, Sven Joachim wrote:

> On 2016-12-15 08:38 +0100, Matthias Klose wrote:
>
>> On 14.12.2016 21:05, Sven Joachim wrote:
>>> Source: readline
>>> Version: 7.0-1
>>> Tags: buster sid
>>> Control: block 848163 by -1
>>> 
>>> I intend to remove the ncurses multilib packages after the stretch
>>> release, see #848163.  Since ncurses is required to build readline, this
>>> means that the readline multilib packages can then no longer be built.
>>> 
>>> There are no reverse dependencies of the readline multilib packages, so
>>> removing them should not be a problem.
>>
>> Did we stop building gdb64 packages for 32bit architectures?
>
> Yes, since gdb 7.9-1.
>
>> I'd like to delay that change until the buildds can manage dependencies on
>> foreign architectures.
>
> Has there been any progress on that?  Bug #770925 has not seen any
> updates for 16 months. :-(
>
> Which use case of foreign architecture dependencies is handled by the
> existing readline multilib packages?

Also, while installing foreign architecture packages might sometimes be
useful, linking a program in a newly built package against a shared
foreign-arch library is not really possible, because dpkg-shlipdeps will
generate incorrect dependencies for it.

There is an overdue ncurses library transition (#230990) in the works,
and I do not want to introduce lib32ncurses6 etc. to the archive.
Attached is a patch which removes the readline multilib packages.

diff -Nru readline-7.0/debian/changelog readline-7.0/debian/changelog
--- readline-7.0/debian/changelog	2017-05-15 22:00:23.0 +0200
+++ readline-7.0/debian/changelog	2018-02-10 11:17:01.0 +0100
@@ -1,3 +1,10 @@
+readline (7.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the multilib packages (Closes: #848168).
+
+ -- Sven Joachim   Sat, 10 Feb 2018 11:17:01 +0100
+
 readline (7.0-3) unstable; urgency=medium
 
   * Apply upstream patches 002 and 003. Closes: #852750.
diff -Nru readline-7.0/debian/control readline-7.0/debian/control
--- readline-7.0/debian/control	2017-01-24 16:19:24.0 +0100
+++ readline-7.0/debian/control	2017-11-05 17:21:36.0 +0100
@@ -4,11 +4,9 @@
 Maintainer: Matthias Klose 
 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9),
-  libtinfo-dev, lib32tinfo-dev [amd64 ppc64],
+  libtinfo-dev,
   libncursesw5-dev (>= 5.6),
-  lib32ncursesw5-dev [amd64 ppc64], lib64ncurses5-dev [i386 powerpc sparc s390],
-  mawk | awk, texinfo, autotools-dev,
-  gcc-multilib [amd64 i386 kfreebsd-amd64 powerpc ppc64 s390 sparc]
+  mawk | awk, texinfo, autotools-dev
 
 Package: libreadline7
 Architecture: any
@@ -25,19 +23,6 @@
  The GNU history library provides a consistent user interface for
  recalling lines of previously typed input.
 
-Package: lib64readline7
-Architecture: i386 powerpc s390 sparc
-Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
-Section: libs
-Priority: optional
-Description: GNU readline and history libraries, run-time libraries (64-bit)
- The GNU readline library aids in the consistency of user interface
- across discrete programs that need to provide a command line
- interface.
- .
- The GNU history library provides a consistent user interface for
- recalling lines of previously typed input.
-
 Package: readline-common
 Architecture: all
 Multi-Arch: foreign
@@ -74,21 +59,6 @@
  .
  This package contains development files.
 
-Package: lib64readline-dev
-Architecture: i386 powerpc s390 sparc
-Depends: lib64readline7 (= ${binary:Version}), ${devxx:Depends}, ${misc:Depends}
-Conflicts: lib64readline6-dev, lib64readline-gplv2-dev
-Provides: lib64readline6-dev
-Section: libdevel
-Priority: optional
-Description: GNU readline and history libraries, development files (64-bit)
- The GNU readline library aids in the consistency of user interface
- across discrete programs that need to provide a command line
- interface.
- .
- The GNU history library provides a consistent user interface for
- recalling lines of previously typed input.
-
 Package: libreadline7-dbg
 Architecture: any
 Depends: libreadline7 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
@@ -119,34 +89,6 @@
  .
  See the ledit and rlwrap packages for other programs of that kind.
 
-Package: lib32readline7
-Architecture: amd64 ppc64
-Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
-Section: libs
-Priority: optional
-Description: GNU readline and history libraries, run-time libraries (32-bit)
- The GNU readline library aids in the consistency of user interface
- across discrete programs that need to provide a command line
- interface.
- .
- The GNU history library provides a consistent user interface for
- recalling lines of previously typed input.
-
-Package: lib32readline-dev
-Architecture: amd64 ppc64
-Depends: lib32readline7 (= ${binary:Version}), lib32tinfo-dev, ${devxx:Depends}, ${misc:Depends}
-Conflicts: lib32readline6-dev, 

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

On 2016-12-15 08:38 +0100, Matthias Klose wrote:

> On 14.12.2016 21:05, Sven Joachim wrote:
>> Source: readline
>> Version: 7.0-1
>> Tags: buster sid
>> Control: block 848163 by -1
>> 
>> I intend to remove the ncurses multilib packages after the stretch
>> release, see #848163.  Since ncurses is required to build readline, this
>> means that the readline multilib packages can then no longer be built.
>> 
>> There are no reverse dependencies of the readline multilib packages, so
>> removing them should not be a problem.
>
> Did we stop building gdb64 packages for 32bit architectures?

Yes, since gdb 7.9-1.

> I'd like to delay that change until the buildds can manage dependencies on
> foreign architectures.

Has there been any progress on that?  Bug #770925 has not seen any
updates for 16 months. :-(

Which use case of foreign architecture dependencies is handled by the
existing readline multilib packages?

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Matthias Klose]

On 14.12.2016 21:05, Sven Joachim wrote:
> Source: readline
> Version: 7.0-1
> Tags: buster sid
> Control: block 848163 by -1
> 
> I intend to remove the ncurses multilib packages after the stretch
> release, see #848163.  Since ncurses is required to build readline, this
> means that the readline multilib packages can then no longer be built.
> 
> There are no reverse dependencies of the readline multilib packages, so
> removing them should not be a problem.

Did we stop building gdb64 packages for 32bit architectures?

I'd like to delay that change until the buildds can manage dependencies on
foreign architectures.

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

Control: clone -1 -2
Control: reassign -2 src:readline6

On 2016-12-14 21:05 +0100, Sven Joachim wrote:

> Source: readline
> Version: 7.0-1
> Tags: buster sid
> Control: block 848163 by -1
>
> I intend to remove the ncurses multilib packages after the stretch
> release, see #848163.  Since ncurses is required to build readline, this
> means that the readline multilib packages can then no longer be built.
>
> There are no reverse dependencies of the readline multilib packages, so
> removing them should not be a problem.

For completeness' sake I'm reassigning a copy to readline6, although you
probably want to remove that in the near future anyway (#840397).

Cheers,
   Sven

Bug#848168: readline: Please drop the multilib packages

[Sven Joachim]

Source: readline
Version: 7.0-1
Tags: buster sid
Control: block 848163 by -1

I intend to remove the ncurses multilib packages after the stretch
release, see #848163.  Since ncurses is required to build readline, this
means that the readline multilib packages can then no longer be built.

There are no reverse dependencies of the readline multilib packages, so
removing them should not be a problem.