Re: Please make a separate package for mistune 2.x
> 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. i wouldnt expect much maintenance needed tho: 0.8.4 is essentially dead upstream, so it will only need to be kept around until its rdeps are ported to mistune 2.x the proposal is "okay", it has the downside of requiring the current rdeps to be updated to point to the new binary package name for the old mistune, but it leaves the namespace open for mistune 2 to take over python3-mistune bin pkg -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Please make a separate package for mistune 2.x
Nilesh Patra 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
signature.asc
Description: PGP signature
Bug#1005043: lintian: check that Python version numbers are not 0.0.0
Package: lintian Version: 2.111.0 Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org I just ran into several Python packages that install modules with version number 0.0.0 because of some issue with their setup.py scripts. I just did the following on my testing system: lz4cat /var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info/PKG-INFO' | wc -l 24 lz4cat /var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info ' | wc -l 6 So there are at least about 30 packages with this problem. The test for this bug (and it should probably be recorded as an error, not just a warning, as no Python package should have a version number of 0.0.0) is simple: if the binary package contains has a file or directory with the name as in the above regex, then the package has this error. Best wishes, Julian
Re: Please make a separate package for mistune 2.x
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
OpenPGP_signature
Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
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
