Re: Using release-monitoring.org [was: uscan roadmap]
On December 3, 2021 12:12:47 PM UTC, Stephan Lachnit <stephanlachnit@debian.org> wrote:
>On Thu, Dec 2, 2021 at 11:52 PM Paul Wise <pabs@debian.org> wrote:
>>
>> On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote:
>>
>> > If I understand correctly, release-monitoring already offers such a
>> > mapping [1].
>>
>> It seems like the Ayanita distro mapping needs to be done manually once
>> per package, while using the Repology data would automatically get us
>> the mapping for each existing package and all future packages.
>
>I mean it looks rather easy to do, just a couple of mouse clicks.
>Compare that to writing a watch file at the moment (assuming one has
>to do more than copy and paste the github example).
>
>> > Hm, I can't really think of an example where such a thing couldn't
>> > also be implemented in release-monitoring.org.
>>
>> None of the three use-cases I listed can be done by it AFAICT.
>>
>> It can't check things that it doesn't have a check for, while
>> individual package maintainers in various distros will update their
>> packages and Repology will notice the new versions.
>
>Then the maintainer would just have to write a check, just like they
>have to do now.
>
>Also, mapping on Repology sometimes needs to be adjusted manually. And
>sometimes they disagree and instead tell you to rename the source
>package in the distro (happened to me once), which is not really
>viable in Debian.
>
>> It presumably doesn't look at the versions for all distros, so it can't
>> do the cross-distro VCS snapshot choice check, while individual package
>> maintainers in various distros know their packages well and might
>> upgrade to a VCS snapshot in their distro, which Repology notices.
>
>Yes it can't, but also I don't think this is something *release
>monitoring* should do. It is definitely a good use case and that is
>why there is a link to repology on the tracker (called "other
>distros"), but it has IMHO nothing to do with *automatic* release
>monitoring. Don't get me wrong, I actually like repology exactly for
>this particular reason.
>
>> It also isn't going to check locations it doesn't check yet, while
>> individual package maintainers in other distros might do that after
>> noticing their package hasn't been updated recently and then going
>> searching for a new upstream and updating, which Repology notices.
>
>Fair point, but if we would work together on release-monitoring.org
>with Fedora, there are more eyes on it as well as in the current
>situation.
>Repology still has more eyes of course, but then again the link to
>Repology is right there on the tracker already if one is curious.
>
>> > Just one quick idea I had: what about a "fake" uscan backend? I.e.
>> > something like `Version: release-monitoring.org` in d/watch. In that
>> > case uscan will launch an external program that fetches the data from
>> > there and gives it back to uscan, so that other tools stay unaffected
>> > until a full transition is done.
>>
>> Excellent idea, that would be great to have.
>
>One more thought on this. If we go with version 5, maybe something like:
>
>Version: 5
>Source: release-monitoring.org
>
>Would also work for multiple sources then and in general would fit
>nicely to the current idea for v5. It also solves the problem with the
>tooling, watch files and uscan would still exist, but the "searching"
>portion is offloaded.
>
>> The one issue I can think of with using release-monitoring.org is that
>> Debian becomes more reliant on an external service, while currently we
>> are completely independent of other distros for version checking.
>>
>> Converting the release-monitoring.org check to a watch file might be an
>> alternative to using it directly that maintains our independence.
>
>Hm right, independence is a valid concern. Anitya itself is open
>source [1] so we could host it easily, but of course the real problem
>would be the stored data of the projects. I don't know if they are
>hosted somewhere, but I'm sure the Fedora guys would be open to share
>them with us, so that we could easily spin up a mirror in case there
>are any problems (it's probably a good idea to host a read-only mirror
>just in case).
>
>This sounds more reasonable to me than writing a tool that converts a
>new standard to the old one just as backup.
I think that there's a security consideration associated with all these proposals for externalizing finding upstream updates. Currently watch files and at least the redirectors I know of all run on Debian infrastructure or on the systems of the Debian person doing the update.
If one of these services were ever compromised it would provide a vector for offering substitute upstream code (at least for the cases where upstream releases aren't both signed by upstream and verified in Debian). I find that prospect concerning.
Scott K
Reply to: