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.

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

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

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.

Yes, since gdb 7.9-1.

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

Control: tags -1 + patch

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.

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

that's not how cross builds are supposed to work. build with dpkg-buildpackage
-a <target>. 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

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

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

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

Cheers,
       Sven

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.

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.

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

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.

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

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

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

Hi Sven,

It may be suitable to revisit removing readline multilibs. During
DebConf Brest we (and that includes Matthias) reached consensus that the
long term goal is getting rid of multilib.

Yes, building gdb64 should work with multiarch libraries, but we still
cannot upload such a thing to the archive due to the required cross
architecture dependencies. Arguably, we didn't have gdb64 in the archive
since quite a while and outside the archive such dependencies can be
dealt with. I argue that removing these multilibs is probably ok now
also considering that i386 is dropping more and more features (linux
kernel, qemu, science packages, ...) already.

Helmut