Hi! On Thu, 2024-11-07 at 02:01:49 +0000, Colin Watson wrote: > On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote: > > 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.
Right, see below… > > 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? Ah I assumed the sources were being taken from pypi, if they are taken from GitHub, then that explains yes. Perhaps using https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan is happy with that one), would solve that problem? (And if it does, then perhaps python packages should be progressively transitioned to use pypi URLs to avoid this kind of problem?) But I'm thinking that, perhaps the best option is to ask upstream directly, whether they are going to release a 2.1.x release soon, or if they could do that now, and/or whether they could perhaps remove/rename the git tag perhaps (with the implied issues with messing with history and git tags being sticky on cloned repos)? As I assume other downstreams might be in the same/similar situation? Thanks, Guillem
