XPost: linux.debian.bugs.dist
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)