On 2024-04-03 23:46:43 +0200, Andrea Bolognani wrote:
> On Tue, Apr 02, 2024 at 12:02:53AM +0200, Sebastian Ramacher wrote:
> > On 2024-04-01 23:39:37 +0200, Andrea Bolognani wrote:
> > > The problem with it, and the reason why a manual dependency is used
> > > in that case, is that ${shlib:Depends} will not pick it up, since
> > > it's dlopen()ed rather than linked against.
> > >
> > > Do you have any suggestions on how to handle this in a way that plays
> > > well with the 64-bit time_t transition?
> >
> > You could derive it from the the dependencies of libxt-dev during the
> > build or for the time being simply change the dependency based on the
> > rename of the libxt6 -- provided that spectrwm is compatible with the
> > new ABI.
>
> I just created [1] which should take care of the issue. It would be
> nice if you could take a look.
I have no idea what spectrwm is doing, so I am probably not the best one
to ask. From the time_t transition perspective, it is an improvement.
> To be honest, I haven't followed the 64-bit time_t transition very
> closely. Do I understand correctly that the SONAME has been changed
> without renaming the files on disk at the same time? That feels kinda
> weird, but I guess it has the nice side-effect of not breaking [2],
> so that's good :)
>
> I also see that libxt6t64 Provides: libxt6, so I'm not sure why the
> dependency on the old name would be a problem? Wasn't that introduced
> specifically to take care of this sort of things?
The libxt6 Provides is only available on architectures where the ABI did
not change. On armhf and armel, the Provides is not present and so the
dependency is not satisfiable.
Cheers
--
Sebastian Ramacher
