XPost: linux.debian.devel.mentors

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

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRdzi5+nDsc/9M1wdeLIp0vfMwE8gUCZ60nWQAKCRCLIp0vfMwE 8s2xAQDHrl5/xFnBar3ccye0PyNkUMZs7F66v1cyFlHYTy/AVQD/eQnJ6ntPYyjE XR9PQzEk3BQVRlIy2LwBavcZXCOzowk=
=Pl5g
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)