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? Thanks in advance, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: PGP signature
