[Pkg-mailman-hackers] [Pkg-matrix-maintainers] Bug#1002380: drops attributes used by reverse dependencies

[Jonas Smedegaard]

Quoting Pierre-Elliott Bécue (2021-12-22 21:42:41)
> 
> Jonas Smedegaard <dr at jones.dk> wrote on 22/12/2021 at 21:55:13+0100:
> 
> > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 2021-12-22T21:55:09+0100 using RSA]]
> > Quoting Pierre-Elliott Bécue (2021-12-22 17:08:46)
> >> Jonas Smedegaard <dr at jones.dk> wrote on 22/12/2021 at 
> >> 12:37:21+0100:
> >> > Releasing a new major release of mistune has caused several 
> >> > packages to no longer be usable at all.
> >> >
> >> > I consider this a serious issue, and have raised severity 
> >> > accordingly.
> >> >
> >> > At least python-m2r have no support for mistune v2 in sight (and 
> >> > its newer fork - python-m2r2 - does not either). Concretely I 
> >> > propose to revert this by a (messy) 2.0.0+really0.8.4 release 
> >> > until reverse dependencies can use the newer major version of 
> >> > mistune.
> >> >
> >> > It seems that a release of python3-django-hyperkitty requiring 
> >> > mistune v2 has already been uploaded to unstable as well.  That 
> >> > is very unfortunate, and will need to be rolled back as well.  
> >> > Mailman maintainers cc'ed.
> >> >
> >> > Please in future make sure to check reverse dependencies *before* 
> >> > releasing a major new upstream release to unstable, because 
> >> > reversal is messy (complicates package versioning).
> >> >
> >> >
> >> > Kind regards, and thanks for maintaining mistune,
> >> 
> >> The issue is that many reverse dependencies of mistune are not 
> >> maintained.
> >
> > I assume (in good faith) that you did not mean to say that the 
> > _Debian_ packages reverse depending on mistune are all unmaintained.
> 
> I'm not sure that there is anything to assume. I wrote "many reverse 
> dependencies of mistune are not maintained", and making it mean "the 
> _Debian_ packages reverse depending on mistune are all unmaintained" 
> would require some hard work.
> 
> > Please note that I did not propose to wait until _upstreams_ of 
> > reverse dependencies can use newer major version of mistune.
> 
> Well, I was under the impression that
> 
> >>> Concretely I propose to revert this by a (messy) 2.0.0+really0.8.4 
> >>> release until reverse dependencies can use the newer major version 
> >>> of mistune.
> 
> meant indeed to wait until the reverse dependencies were sorted out 
> which generally requires to wait until upstream fixes the issue 
> (except if one likes big quilt patches and maintaining the software's 
> code on their own).

That is precisely what I did *not* imply (so it seems it was good that I 
mentioned my non-assumption since apparently you _did_ assume stuff).  

Let me try avoid false assumptions by expanding:

I propose to revert this by a (messy) 2.0.0+really0.8.4 release until 
reverse dependencies somehow (with or without upstream cooperation) can 
use the newer major version of mistune (or, if taking unreasonably long, 
kick any reverse dependencies from testing).


> > My proposal is to *collaborate* with your peers in Debian now - not 
> > continue(!) to make choices without coordination with those packages 
> > directly affected by those choices.
> 
> Maybe you wanted to suggest that I should *collaborate* more, but you 
> did not write that and, as I tend to try not to assume what one says, 
> writes or means, I did not read that.

Sorry!

I did indeed mean to encourage more collaboration, and apologize if that 
failed to get across.


> >> If I follow your opinion on this, the following issues arise:
> >> 
> >>  1. There is no proper way for software to be mistune 0.8.4 and 
> >>     mistune 2.0.0 compatible at the same way, so the reverse 
> >>     dependencies won't be able to update without mistune 2.0.0 
> >>     being in unstable
> >
> > Not sure what you imply by "proper".
> 
> appropriate, suitable, relevant, reasonable, …
> 
> > There are alternatives to abruptly abandoning support for existing 
> > functionaling packages already in Debian testing.
> 
> Note that since the upload, autopkgtests for the involved 
> reverse-dependencies were failing and therefore mistune was not 
> planned to migrate from unstable to testing. There was therefore no 
> chance mistune would break these packages in testing, and I was not 
> pressing anyone to sort that out.
>
> Now that a serious bug against mistune is opened, even if these 
> autopkgtests get sorted out because these very reverse-dependencies 
> are updated, mistune will not migrate anyway (which will prevent to 
> break other reverse-dependencies).

Yes, I am aware, and that is what I describe as "abruptly": Now that 
mistune v1 is gone, there is no way to work on any package depending on 
that except for switching to v2.

...which is the reason I propose to revert for now.


> Testing is not impacted so far.

Correct.  Unstable is impacted.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-mailman-hackers/attachments/20211222/77820666/attachment-0001.sig>