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

Matthias Klumpp mak at debian.org
Tue Mar 19 21:55:31 GMT 2024


Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie <smcv at debian.org>:
>
> 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 <smcv at debian.org>:
> > > 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...)



More information about the pkg-gnome-maintainers mailing list