Path: csiph.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Jerome Charaoui Newsgroups: linux.debian.bugs.dist,linux.debian.maint.python Subject: Bug#1003567: Please make a separate package for mistune 2.x Date: Fri, 04 Feb 2022 18:40:02 +0100 Message-ID: References: X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Fri Feb 4 17:36:08 2022 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -6.451 Reply-To: Jerome Charaoui , 1003567@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debian Python Team X-Debian-Pr-Message: followup 1003567 X-Debian-Pr-Package: python3-schema-salad X-Debian-Pr-Source: python-schema-salad X-Riseup-User-ID: DAD3615C900303008A86937FFB3D891FE9163A1A430222C172A3858CC2579DA1 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Debian-Message: from BTS X-Mailing-List: archive/latest/1703548 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 69 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Pierre-Elliott =?UTF-8?Q?B=C3=A9cue?= , "Michael R. Crusoe" , 1003567@bugs.debian.org, debian-python@lists.debian.org X-Original-Date: Fri, 4 Feb 2022 12:33:29 -0500 X-Original-Message-ID: X-Original-References: <20220111213844.BE33D2C006E@pimeys.fr> <878rurbmr3.fsf@jaatynyt> <89a82b8a-ea47-fedf-d9f9-7a4c6edaf79e@tchncs.de> <20220111213844.BE33D2C006E@pimeys.fr> <89a82b8a-ea47-fedf-d9f9-7a4c6edaf79e@tchncs.de> Xref: csiph.com linux.debian.bugs.dist:1092052 linux.debian.maint.python:13922 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