On Thu, Feb 13, 2025 at 09:23:49AM +0100, Emilio Pozuelo Monfort wrote: > 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 > Ah, OK, so these uploads all require FTP master review right?
- soname bump to 0.5.5 in experimental - initial upload of the new pykdumpfile in experimental - dropping python bindings in experimental - 0.5.5 without python in unstable (or can I as a DM do this myself?) - pykdumpfile in unstable If a package that's been cleared for experimental can be uploaded to unstable without FTP master review, even if it has binary subpackage name changes, that would simplify this quite a bit (but if it requires re-review, that's fine too, I just have to know how much to coordinate with the DD sponsoring the upload) Thanks Emilio! -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: PGP signature
