Hi, 在 2023-02-21星期二的 01:16 +0200，Peter Pentchev写道： > On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote: > > On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote: > > > Hi, > > > > > > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道： > > > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum <lu...@debian.org> > > > > wrote: > > > > > Source: python-zstandard > > > > > Version: 0.19.0-3 > > > > > Severity: serious > > > > > Justification: FTBFS > > > > > Tags: bookworm sid ftbfs > > > > > User: lu...@debian.org > > > > > Usertags: ftbfs-20230216 ftbfs-bookworm > > > > > > > > > > Hi, > > > > > > > > > > During a rebuild of all packages in sid, your package failed to > > > > > build > > > > > on amd64. > > > > > > > > At the moment this is creating quite > > > > the havoc with making a bunch of things FTBFS as well (see merhged > > > > bugs) > > > > > > > > This is likely due to py-zst trying to link with the zstandard in > > > > the > > > > archive > > > > which does not seem to go very well. > > > > > > > > Is someone working to fix this? > > > > > > Thanks for cc-ing. I did not monitor bugs for this package before. > > > > > > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it > > > out > > > and have it packaged. > > > > > > On the long run, the mismatch of src:libzstd and src:python-zstandard > > > will > > > always occur intermittently due to its nature. I am not sure whether > > > re- > > > enabling bundled libzstd would be a good choice, but at least let's > > > fix the > > > combination for Debian 12 first. > > > > > > Any suggestions? > > > > Oof. Sorry about that. I guess I didn't consider the python-zstandard > > package at all until now. > > > > As I am a member of both the pkg-rpm and pkg-python teams, I could try > > to > > update the packages in sync from now on, possibly adding something like > > Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to > > libzstd itself if it breaks the then-current python-zstandard package. > > (of course, I meant Breaks: python3-zstandard (<< ...)) > > ...of course, another - or rather, an additional - option would be to > relax (or remove) the check that python-zstandard makes regarding > the libzstd version recorded at compile time. Since both libzstd > upstream and the Debian package tries to hold true to the usual > semver-like compatiblity scheme, python-zstandard ought to be able to > believe that even a more recent version of libzstd would be ABI-compatible > unless it has reason to think otherwise - and that case could be handled > by Breaks: python3-zstandard (<< next-version) in libzstd as outlined > above. So maybe (for future new upstream versions of libzstd): > - relax (or remove) the python3-zstandard check for the libzstd version > - each time a new libzstd upload is about to be done, check that > python3-zstandard works, too > - if it works, do nothing else, upload libzstd as usual > - if python3-zstandard would for some reason break and needs updating, > hold off with the libzstd upload until an updated version of > python3-zstandard is released upstream, make sure it will work, and > only then upload libzstd with a Breaks declaration > - upload the updated version of python3-zstandard immediately (maybe > even simultaneously) and declare a Depends relationship on > the just-uploaded version of libzstd (as it does now) > > If this sounds good, I believe I can do it that way for future libzstd > uploads.
There are surely many possibilities as long as we are aware of such versioned dependency and coordinate on the uploads. Since you are also in python packaging team, please feel free to make modifications and do team uploads to python-zstandard in the future if you find it necessary. Thanks! Best, Boyuan Yang
signature.asc
Description: This is a digitally signed message part
