Le 2022-02-04 à 11 h 24, Nilesh Patra a écrit :
On 2/4/22 9:33 PM, Julian Gilbey wrote:
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see
/usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.
But that'd lead to a number of mistune's embedded copies in a huge
number of packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new
version. When they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then
all such packages would be
effected, and that honestly does not look like a good idea to me.
This is true, though there are only 7 reverse dependencies currently
in testing.
Yeah, in total the reverse-deps are 8 and there is one different
reverse-build-dep (pasted at end of this mail)
But the problem is if these fall through the cracks, and close to the
release we notice some
package is not looking nice.
Also, if you suppose that the upstreams are very slow, and we get to the
new debian release with these things still
embedded, it'd be a real mess to upload fixes to stable, right...
I somehow do not understand the urgency of uploading this newer
version, as the maintainer said:
| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).
We could simply wait a little more for the dust to settle, IMHO.
That would be a reasonable approach, but how long will it take for the
dust to settle? With this major change, and no guidance from upstream
on how to migrate, and at least a number of upstream authors happy to
rely on setup.py having "mistune <1.0.0" in the install_requires
field, it might be several months or longer before things are fixed
upstream.
I think we could do this transition even a month or two before the soft
freeze starts,
which is roughly an year from now (considering general trend timings of
starting in feb in release year).
Situation might improve by then, I suppose.
If it does not, we could still go ahead with the older python3-mistune
in the archive, I do not see
a huge problem there, except for maybe a few mistune uploads to stable
if desired.
And what do we do when some packages have converted and
some haven't?
In such a case, we atleast will have a few examples to see how to go
about doing the API changes the right way.
We could patch out at our end and send the changes upstream for review
provided we are stuck in an unfortunate situation.
FWIW, there's a recent patch and PR for the lektor upstream which add
mistune 2.x support, so for this particular project I don't think a
separate package is necessary.
-- Jerome
