On Tue, Jan 30, 2024 at 03:18:23PM +0000, Lukas Märdian wrote:
> Source: gap
> Version: 4.12.1-2
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> Dear maintainer,
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for gap
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Hello Lukas, you uploaded 4.12.2-1.1 to experimental.

The upstream version (4.12.2) in experimental should never be uploaded to 
unstable,
because it breaks the build interface. There will be a new upstream version 
(4.13.0)
with a new soname (libgap.so.9) that will replace it and that I will eventually
upload to unstable.

Secondly, your patch do not actually make libgap8t64 to actually use 64-bit 
time_t,
and it seem very dangerous to have a library named libgap8t64 that do not 
actually
use 64-bit time_t.

There is a single package that depend on libgap8 (python3-sage) and it is 
seriously
out of date, so we should probably wait for the new upstream version instead of
introducing libgap8t64.

So if one really need to introduce libgap8t64, we need a patch for the version
of GAP in unstable that actually use 64-bit time_t.

Cheers,
-- 
Bill. <ballo...@debian.org>

Imagine a large red swirl here. 

Reply via email to