Nilesh Patra <nilesh@tchncs.de> wrote on 05/02/2022 at 20:23:44+0100:
> [[PGP Signed Part:No public key for 00BAE74B343369F1 created at 2022-02-05T20:23:44+0100 using RSA]]
> 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
I'd like other python team member's opinion on this, and I'm not eager
to maintain that legacy package, as I tend to not want to maintain
obsolete software. Still, I can do the initial work of creating it.
--
PEB
Attachment:
signature.asc
Description: PGP signature