Re: Changed Github download URLs are affecting lots of existing watch files
On Sat, Mar 27, 2021 at 12:26:29PM +0100, Andreas Tille wrote:
> Hi Bart,
>
> On Sat, Mar 27, 2021 at 07:38:17AM +0100, Bart Martens wrote:
> > On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote:
> > > Le 26/03/2021 à 22:38, Andreas Tille a écrit :
> > > > Any idea what to do (besides uploading all packages obtained from
> > > > Github right after the release)?
> > >
> > > This breaks also more than thousand package from JS Team.
> > >
> > > We could perhaps handle that with uscan then each time GitHub changes
> > > its website, only uscan should be updated.
> >
> > Yes. Or maintain watch files outside the packages.
>
> Fine for me - but what is our QA tool chain using. As far as I know
> tracker.d.o and other tools are relying on UDD and the information is
> fed from the uploaded watch file. Or am I wrong with this assumption?
Not sure. A long time ago uscan results were used directly in pts and ddpo
without going via UDD.
>
> > Or use "fakeupstream.cgi"
> > for popular platforms like github.
> > https://salsa.debian.org/qa/qa/blob/master/cgi-bin/fakeupstream.cgi
>
> For the moment there are four suggestions for watch files maintained
> inside the package:
>
> 1. use the string suggested in `man uscan`
> https://github.com/<user>/<project>/tags (?:.*?/)?v?(\d[\d.]*)\.tar\.gz
>
> 2. enable uscan to interpret some @GITHUBREGEX@
Once place to update feels right, but stuffing uscan with platform (like
github) specific things is not the best design imho. And releasing an updated
uscan is also a bit slower than maintaining watch files outside the packages.
>
> 3. asking for a new github redirector on qa.debian.org as there
> is for sf.net (or PyPI)
Adding more scripts like sf.net looks like slightly more work than integrating
in the uniform approach in fakeupstream.cgi.
>
> 4. use "fakeupstream.cgi" (this service is new to me)
Originally meant for exotic upstreams, low volume. Using it for popular platforms
like github as well would increase the volume, but certainly worth considering.
>
> All suggestions sound promising to me to be more sustainable than the
> current situation.
> For sure it would mean editing *lots* of d/watch
> files (and upload once the new release cycle will start)
True! 1-4 indeed involve that.
> I wonder
> whether we could come up with some suggestion which of these (or may
> be even other suggestions?) is the most promising one and all those
> who now feel forced to change their watch files will possibly change
> to the same string (automatically) instead of picking a random option.
Using watch files outside the packages would solve the problem for the qa tool
chain.
>
> I admit my prefered way would be to do this via lintian-error plus
> lintian-brush to cure the issue.
That I have no knowledge of, so far. I have no strong preference, so go ahead
without waiting for me, np.
B.
Reply to: