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

Reply via email to