Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:55:31 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
> > Yes, the library is renamed on all architectures. (On architectures where
> > the ABI didn't actually break, like amd64, it Provides the old name.)
>
> So, in that case the most straightforward way to fix this would just
> be to rename the dependency to libgtk-3-0t64?

Yes, that'll be the simplest approach.

smcv

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
>
> On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> > Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > > to be replaced by libgtk-3-0t64 after checking that the functions that
> > > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> >
> > Will this be the new name on all platforms?
>
> Yes, the library is renamed on all architectures. (On architectures where
> the ABI didn't actually break, like amd64, it Provides the old name.)
>
> The same is true for essentially all of the libraries involved in this
> transition: there are hundreds of them.
>
> > Annoyingly, libgtkd does not depend on
> > libgtk properly on its own via linking it, and instead will dlopen it
> > at runtime.
>
> One way I've sometimes seen this handled is by making a list of the
> SONAMEs that will be dlopen'd, linking them into a dummy C executable
> with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
> and generate dependencies.

So, in that case the most straightforward way to fix this would just
be to rename the dependency to libgtk-3-0t64?
(making a mock library is possible, but I'd prefer the easiest way in
this case, as it's just one library...)

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > to be replaced by libgtk-3-0t64 after checking that the functions that
> > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> 
> Will this be the new name on all platforms?

Yes, the library is renamed on all architectures. (On architectures where
the ABI didn't actually break, like amd64, it Provides the old name.)

The same is true for essentially all of the libraries involved in this
transition: there are hundreds of them.

> Annoyingly, libgtkd does not depend on
> libgtk properly on its own via linking it, and instead will dlopen it
> at runtime.

One way I've sometimes seen this handled is by making a list of the
SONAMEs that will be dlopen'd, linking them into a dummy C executable
with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
and generate dependencies.

smcv

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Matthias Klumpp]

Hi Simon!

Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> to be replaced by libgtk-3-0t64 after checking that the functions that
> interact with time_t (methods of GtkRecentInfo) are handled correctly.

Will this be the new name on all platforms? If not, can we detect the
name automatically somehow? Annoyingly, libgtkd does not depend on
libgtk properly on its own via linking it, and instead will dlopen it
at runtime. So that dependency has to be added manually for the Debian
package.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Source: gtk-d
Version: 3.10.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
to be replaced by libgtk-3-0t64 after checking that the functions that
interact with time_t (methods of GtkRecentInfo) are handled correctly.

There might be other library dependencies in a similar situation: I suggest
using this bug report to represent all of them, rather than having multiple
bugs to track this.

More information about this transition is available on
.

Thanks,
smcv