Dear all,

I am intending to package a new dependency of textdistance called
rapizfuzz (along with its dependencies jarowinkler and rapizfuzz-capi,
and including rapizfuzz-cpp and jarowinkler-cpp within the packages).
It's relatively low priority though (and I haven't filed ITPs yet).
But it needs cython 3.0.0alpha7 or later to be able to compile.

There is talk of moving cython 3.0.0 into beta in the not-too-distant
future: https://github.com/cython/cython/issues/4022 It does have
some breaking changes in comparison to cython 0.29.x.

I wonder what our strategy should be? Here are three reasonable
approaches:

(1) Keep the existing cython package (source: cython, binaries:
cython3, cython-doc, cython3-dbg) and have a new package for the 3.*
releases.

Advantages:
* won't break lots of existing packages

Disadvantages:
* no obvious name for new package
* will end up with an old cython package over time that cannot be
easily dropped
* will lead to confusion - what is the cython3 package, is it the new
or old version of cython?

(2) Create a new cython0.29 package (source: cython0.29, binaries: cython3-0.29, cython0.29-doc, cython3-0.29-dbg for example) to house
the "old" version, and the cython package becomes cython 3.0.0

Advantages:
* clear naming scheme
* those packages which "just work" with the new version of cython will
not need to do anything to migrate
* allows the cython0.29 package to be dropped in time without needing
lots of renaming once no packages still rely on it

Disadvantages:
* there are two packages to maintain instead of just one (cython0.29
and cython)
* those packages which don't work with 3.0.0 will either need patching
or their dependency will need to be changed to cython3-0.29

(3) Let the cython package become cython 3.0.0 once it is released.

Advantages:
* only one package to maintain
* keep at the cutting edge of cython development

Disadvantages
* may break lots of packages, requiring a lot of effort to patch them


I don't know how many packages in Debian would be broken by the move
to 3.0.0; that may be something worth exploring. It may well be that
approach (2) makes most sense for the short term.

I imagine that this is unlikely to hit before the bookworm freeze, but
I wanted to flag it up now.

Best wishes,

Julian

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

Hi Julian (2022.08.14_07:41:26_+0000)

I don't know how many packages in Debian would be broken by the move
to 3.0.0; that may be something worth exploring. It may well be that approach (2) makes most sense for the short term.

I think that's the first question to answer. Once we know how bad
the incompatibilities are, we can decide on the best approach.

So, first step is probably to package the new cython version (locally),
and try to rebuild everything against it.

SR

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

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

On Sun, Aug 14, 2022 at 08:49:06AM +0000, Stefano Rivera wrote:

Hi Julian (2022.08.14_07:41:26_+0000)

I don't know how many packages in Debian would be broken by the move
to 3.0.0; that may be something worth exploring. It may well be that approach (2) makes most sense for the short term.

I think that's the first question to answer. Once we know how bad
the incompatibilities are, we can decide on the best approach.

So, first step is probably to package the new cython version (locally),
and try to rebuild everything against it.

That sounds sensible, indeed, once the beta is released. As cython is
used quite widely (240 packages or so in testing), I wonder whether it
would be appropriate to upload it to experimental and ask Lucas to run
the test builds across the archive?

Best wishes,

Julian

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