On 2/6/22 12:20 AM, Julian Gilbey wrote:
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".
Ah, looks like we just had to think in the reverse direction from the initial proposal (mistune-{0,1} instead of mistune-{1,2}).
Indeed, that sounds like a much better plan.
I hope PEB agrees with this as well, would like to hear from them :)
Thanks for the discussion, Julian :)
Regards,
Nilesh
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature