On 12/02/2025 23:57, Michel Lind wrote:
Dear all,
libkdumpfile has recently released version 0.5.5, which despite the
version number, actually contains an soname bump from 0.5.4
https://github.com/ptesarik/libkdumpfile/releases/tag/v0.5.5
See e.g. the relevant Fedora packaging change
https://src.fedoraproject.org/rpms/libkdumpfile/c/c0097ea1c69462b6bb151d186ff4856663c5b7e4?branch=rawhide
The soname bump is fine in itself - I'll change the name of the binary
subpackage containing the shared library files, and the upload will need
to be done by a full Debian Developer and subject to FTP master review
(IIRC, please correct me if I'm wrong).
*But* upstream also decided to drop the legacy Python bindings right
after 0.5.5 is out, and instead recommending the separate pykdumpfile
(which they also maintain)
https://github.com/ptesarik/pykdumpfile
https://src.fedoraproject.org/rpms/python-pykdumpfile
So rather than keeping the Python bindings in 0.5.5 I figured might as
well drop the Python bindings immediately and package the new one.
This needs to be built against the correct libkdumpfile, so I'm a bit
unsure about the sequencing - in Fedora my sequence was:
- package the new libkdumpfile, make it obsolete the old Python
subpackage so upgrades work but result in the Python subpackage being
removed
- then package pykdumpfile
I could have done both in a side tag and avoided having a time where the
Python bindings are not available, but the way Python packages are
generated in Fedora, if the package name changes the virtual provides
they generate change anyway, so pykdumpfile won't be a drop in
replacement even though it ships exactly the same Python module names.
For Debian - since we already require FTP master review for the soname
bump, it seems to make even more sense to also drop the old Python
bindings and avoid requiring a re-review when 0.5.6 comes out.
The question is - is it OK to have unstable temporarily miss the Python
bindings? And should I preserve the upgrade path or let people keep the
old Python bindings? (so apt-upgrade will skip updating libkdumpfile)?
Or is there a way, say build the new libkdumpfile in experimental with
the Python bindings disabled, get the new pykdumpfile reviewed and also
built in experimental, then get them both promoted to unstable?
That is exactly how you should do it.
Alternatively:
- upload the new libkdumpfile with python bindings to experimental
- once it clears new, upload to unstable (beware of the transition, so maybe
request a transition slot by doing `reportbug release.debian.org')
- upload libkdumpfile again to experimental without python bindings
- upload pykdumpfile to experimental
- once pykdumpfile clears NEW, upload both to unstable
Cheers,
Emilio
