Hi David, On Sun, Feb 11, 2024 at 01:37:53AM -0300, David da Silva Polverari wrote: > First of all, thanks for your report and for the work on the transition!
> After having a look at [1] and [2], I found the only reported problem
> was due to the usage of a pointer to the pe_ctx structure (typedef'ed as
> pe_ctx_t) [3] as the first parameter of the exported functions from
> libpe, as its map_size field is of type off_t ("Base type has been
> changed from long to long long. Recompilation of a client program may be
> broken.").
> The output of `apt rdepends libpe1` shows that only the binaries built
> by readpe depend on it. Besides, within readpe itself, there is only one
> mention to accessing the map_size field directly outside of libpe, and
> it is commented out [4].
> That said, I am not sure that including readpe in the transition will be
> necessary, but maybe I have overlooked something. But I thought I should
> add this information here.
Note that the libpe1 reverse-dependency, readpe, does not have a strict
versioned dependency on libpe1 but instead gets its dependency from shlibs.
So a partial upgrade, for whatever reason, of readpe without libpe1 or
libpe1 without readpe could still cause ABI skew and possible crashes.
However, readpe is also a new package to the Debian archive, having only
been around since September; so upgrades from stable releases are not an
issue and third-party packages are likely an ignorable concern.
If you are maintainer are happy to take responsibility for the (unlikely)
crashes that may occur in the partial upgrade case, then it's fine for you
to close this bug, in which case we will not NMU to unstable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
[email protected] [email protected]
signature.asc
Description: PGP signature
