Re: Changed Github download URLs are affecting lots of existing watch files
On Sat, Mar 27, 2021 at 10:18 AM Gard Spreemann wrote:
> Phil Morrell writes:
>
> > Sounds like you're asking for a new github redirector on qa.debian.org
> > as there is for sf.net, which could use the official api for stability.
FTR there is one of those here:
https://qa.debian.org/cgi-bin/fakeupstream.cgi
https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/fakeupstream.cgi
> This got me thinking: the version checking mechanism of d/watch files is
> useless if the outside world changes, i.e. if upstream's URLs
> change. Why do we then ship this logic with the packages at all, when
> packages are meant to be useful for an extended amount of time? Would it
> not be better to decouple the version-checking aspect of d/watch
> entirely from the actual package tarball?
We had this before but it died when we switched from alioth:
https://wiki.debian.org/qa.debian.org/HowToHelpWithFixingWatchFiles?action=diff&rev1=23&rev2=24
The problem with it was that it was entirely separate to the
maintainer's files so it was often different to their preferred way of
doing things. One option for doing this more optimally would be to add
some code to vcswatch to extract debian/watch files from the Vcs-*
repos and pass those to UDD, which could then run uscan with the VCS
debian/watch files where they are newer than the package.
Some additional points for the thread in general:
I would suggest packages using GitHub are better off using the uscan
git mode rather than the GitHub releases/tags pages, since those are
now paginated and don't list all tags/releases.
It might be interesting to look at how Fedora monitors new upstream releases.
https://release-monitoring.org/
https://fedoramagazine.org/how-fedora-monitors-upstream-releases/
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: