Subject: readline: Please drop the multilib packages
Date: Wed, 14 Dec 2016 21:05:54 +0100
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.
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Wed, 14 Dec 2016 20:30:04 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Wed, 14 Dec 2016 21:21:21 +0100
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
Acknowledgement sent
to Matthias Klose <[email protected]>:
Extra info received and forwarded to list.
(Thu, 15 Dec 2016 07:39:07 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Thu, 15 Dec 2016 08:38:22 +0100
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.
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Thu, 15 Dec 2016 20:30:08 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Thu, 15 Dec 2016 21:28:40 +0100
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
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Sat, 10 Feb 2018 12:45:03 GMT) (full text, mbox, link).
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.
Acknowledgement sent
to Matthias Klose <[email protected]>:
Extra info received and forwarded to list.
(Sat, 10 Feb 2018 14:03:03 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 10 Feb 2018 15:00:51 +0100
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?
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Sat, 10 Feb 2018 17:12:04 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 10 Feb 2018 18:09:59 +0100
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
Acknowledgement sent
to Matthias Klose <[email protected]>:
Extra info received and forwarded to list.
(Sat, 10 Feb 2018 17:45:03 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 10 Feb 2018 18:44:00 +0100
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 <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
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Sat, 10 Feb 2018 18:03:02 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 10 Feb 2018 19:00:05 +0100
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 <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.
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
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Fri, 16 Feb 2018 20:09:07 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Fri, 16 Feb 2018 21:06:19 +0100
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
Acknowledgement sent
to Matthias Klose <[email protected]>:
Extra info received and forwarded to list.
(Sat, 17 Feb 2018 02:36:03 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 17 Feb 2018 09:33:01 +0700
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.
Acknowledgement sent
to Sven Joachim <[email protected]>:
Extra info received and forwarded to list. Copy sent to Matthias Klose <[email protected]>.
(Sat, 17 Feb 2018 09:36:03 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sat, 17 Feb 2018 10:32:32 +0100
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
Acknowledgement sent
to Matthias Klose <[email protected]>:
Extra info received and forwarded to list.
(Sun, 18 Feb 2018 01:30:03 GMT) (full text, mbox, link).
Subject: Re: Bug#848168: readline: Please drop the multilib packages
Date: Sun, 18 Feb 2018 08:27:26 +0700
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
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.