On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote: > On Thu, 2024-11-07 at 01:15:08 +0000, Colin Watson wrote: > > https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked > > from PyPI, but it's what we currently have in Debian. Some of the more > > recent releases (which I think are really in the same version series - > > it's just that upstream changed their minds about bumping the patch > > version) contain fixes that we should have in Debian; in particular > > while trying to fix python-srsly I ran into a problem which I think is > > fixed by > > https://github.com/explosion/catalogue/commit/75f5e9c24e93b5fcc2b3e9f324d9328bc871abad. > > > I'm happy to do the work to get us onto a newer version, but I wanted to > > check what to use for the version scheme. Should we use > > 2.1.0+really2.0.10-1 or 1:2.0.10-1? I think there'd be some > > justification for an epoch here since the upstream version numbering > > scheme changed (cf. > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version), > > but I'm copying debian-devel as per policy on epoch proposals. > > The way I see it, this does not look like a version schema change to > me, upstream released a version that they then retracted: > > https://github.com/explosion/catalogue/issues/46
I guess you might or might not describe that as a change in the upstream version numbering scheme, depending on how you interpret policy's language. *shrug* > Given that I assume the current (non-retracted) upstream version is > going to be close to surpass the retracted one, I'd go for the +really > hack. In this case invalidating relationships for external > dependencies would not seem like a big issue, because it looks like > the yanked version is the only one that has ever been in Debian, but > it avoids the ugliness and confusion of epochs (people tend to forget > to add the epoch in relationships for example) and its stickiness, > going forward. I don't really have any information on whether upstream plans a 2.1.1 or similar, but it's true it might well happen. > The other question that comes to mind is why the yanked version was > uploaded, as from that issue above it seems at that time it should > have already been marked as yanked. Perhaps we have some automated > tool that does not honor the yanked markings, which might deserve a bug > report? Andreas do you recall what tool or process you used for that? I'd initially misread it as being just a day or two after the yanked version, but you're right, it was months later. I suspect it was simply uscan - it's using the GitHub tags rather than looking at PyPI, and the tag was never removed, so it's hard to see how it could have known any better. This does leave the question of how to hide that version from uscan in the future, since uscan doesn't make it easy to ignore specific upstream versions and I'd prefer to avoid using opaque regex constructions to do it. My best idea is to use uversionmangle to turn 2.1.0 into something like 2.0.8~pre1, but is there a better idiom? -- Colin Watson (he/him) [cjwat...@debian.org]
