Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 4, 2021 at 3:34 AM Paul Wise <pabs@debian.org> wrote:
>
> Repology gets you mappings for all the source packages in Debian in one
> download (assuming it has an export of the mappings, that may need to
> be added), while the Anitya mapping requires a human to manually add a
> mapping for each of the thousands of source packages in Debian. Not all
> maintainers are going to bother and repetitive clicking is going to get
> boring for the folks trying to make up for that.
I'm sure there would be a way to automate this with repology data.
> > 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.
>
> I wasn't aware of the renaming part, seems kind of weird.
See e.g. [1]:
"Will not merge: Modules (e.g. python) without consistent prefix (e.g.
python- or python3-) (common problem for Slackbuilds and Debian source
packages). [...]"
> > 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.
>
> I was taking the thread topic to be the slightly more general area of
> "monitoring when a package needs updating to a new upstream release,
> snapshot or fork". New VCS snapshots in other distros fits that IMO.
Ah right I see, I guess we then should separate more between fetching
the tarball and scanning for versions to inform the maintainer - I
don't think that these necessarily need to use the same technique. For
informing the maintainer, repology might as well be an additional very
useful tool.
> The other issue with using Anitya is that Debian and Fedora have
> different policies and culture for choosing which upstream versions to
> update to. Debian strongly prefers LTS versions while Fedora are all
> about the latest and greatest, which is a bit of a culture clash and is
> likely to mean for some packages we couldn't use Anitya.
I don't think this is an issue here - see [2]. The response
differentiates between stable versions and other versions. I'm not
sure how RCs are handled, but it would not be that difficult to
implement.
> In addition to independence there is the issue Jonas mentioned
> elsewhere in the initial uscan thread that some Debian people prefer
> the info to be maintained in the source package instead of elsewhere.
Of course this would be optional. Regarding bootstrapping it might not
be that good of an idea to use it for essential packages anyway.
> > This sounds more reasonable to me than writing a tool that converts a
> > new standard to the old one just as backup.
>
> Given the above, perhaps a way to sync a locally stored file and the
> Anitya one, and then have uscan understand the Anitya format?
I've been looking at the api (see [2]) for a bit and while not trying
it out myself, afaik there is no functionality to download a tarball.
While I like the idea of release-monitoring, I now feel like it
doesn't fulfill the needs of Debian and probably newer will. So
putting all watch files in a single salsa repo probably makes more
sense, or something similar to offload it.
On Sat, Dec 4, 2021 at 3:44 AM Scott Kitterman <debian@kitterman.com> wrote:
>
> 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.
Good point, but I think this can be mitigated relatively easily - just
always print the url of the tarball that is downloaded (which is a
good idea anyway). The maintainer should know the url where the
sources are hosted, and if the printed url somehow looks weird, it can
be easily checked.
Stephan
[1] https://repology.org/project/symfit/report
[2] https://release-monitoring.org/static/docs/api.html#post--api-v2-versions-
Reply to: