On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote: > On 2/4/22 9:18 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.
I have just had another idea, which might solve all of the problems: create a new Debian package called mistune0 (or mistune1), which contains the legacy version of mistune, but with the Python module called "mistune0" instead of "mistune". Then it will be co-installable with mistune 2.x, and the packages which still depend on mistune 0.8.4 could be patched to say "import mistune0 as mistune" until they are updated upstream. This will also avoid having multiple copies of the legacy code in the archive, which addresses the security issue, and allow those packages which have migrated to mistune 2.x to still say "import mistune". Best wishes, Julian