Need advice on coordinating libkdumpfile update and introducing pykdumpfile

[Michel Lind]

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,

[Michel Lind]

Post by Michel Lind
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
- 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.
- 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!

[Michel Lind]

Michel,

Post by Michel Lind
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)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.
Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.

Ah, great, thank you!

Best regards,

[Soren Stoutner]

Michel,

Post by Michel Lind
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)

FTP master review is only required when the name of a binary package changes. Any
other change inside the binary package does not require their review.

Because FTP master review can take an unpredictable amount of time, usually the best
course of action in this case would be to make all such changes in experimental (because
it is OK for packages in experimental to not be coinstallable or otherwise introduce
breakage with other packages). Once everything is settled, you can upload a version of
these experimental packages that only changes the target to unstable and they will all
drop in immediately.