On Fri, 2021-12-03 at 13:12 +0100, Stephan Lachnit wrote: > 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). 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. > Then the maintainer would just have to write a check, just like they > have to do now. Or you could get the most recent distro version for free without manual work by using the Repology data. While it isn't always the true latest release from upstream, often the latest distro version being newer than the Debian version is good enough to notify the Debian maintainer to update the package to the true latest release from upstream. > 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. > 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. > 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. Sure, I think we need all three solutions as they all fit different use-cases within the "update to latest release/snapshot/fork" arena; (see below for more about why) debian/watch, Anitya and Repology. There is already a bug about more Repology integration within the package tracker, and I was the one who did the existing tracker integration. > One more thought on this. If we go with version 5, maybe something > like: > > Version: 5 > Source: release-monitoring.org Looks good. > 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. Agreed. > 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). 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. 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. > 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? -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part