avahi.org/download has no file index

[lathiat]

Unlike the previous host, avahi.org/download has no index of files.

Some distributions such as Debian (using debian's debian/watch) file rely on this for their automatic checking of new releases.

We may need to fix this (it's possible to generate such an index with GitHub actions) and/or formalise a move to using GitHub releases or similar.

I know Debian does this, I am not sure who if anyone else does this.

[evverx]

I think it should be possible for Debian to switch to GitHub by analogy with https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/watch. @mbiebl I wonder if it would be possible to switch https://salsa.debian.org/utopia-team/avahi/-/blob/debian/master/debian/watch from avahi.org?

[lathiat]

Yeah they'd totally be up to switch I imagine, I guess we just need to decide if we want to do that or not.

[evverx]

To judge from https://salsa.debian.org/utopia-team/avahi/-/commit/893a2769f18f4c444a186872a329bc5272e9598b Debian switched to GitHub and then switched back to avahi.org due to I assume that bug where GitHub messed up checksums. That change was reverted by GitHub so it should probably be safe to switch back.

I think GitHub releases should be good enough. If someone really needs the download folder they can implement and maintain that action themselves.

[mbiebl]

https://wiki.debian.org/debian/watch#GitHub has some background

I.e. the download links being JS based and one approach is to use api.github.com. The problem is, that access to api.github.com is rate limited.

[mbiebl]

That said, yes, we can adjust debian/watch to use github directly (whether it be releases or tags).

Just curious: Is it still planned to release full make dist tarballs or only git tag snapshots?

[evverx]

Personally I'd switch to snapshots (and maybe signed tags eventually) because it's easier to maintain. That being said if I used tarballs I wouldn't be happy about this because I don't trust snapshots generated by GitHub :-) I guess it depends on avahi/avahi#449.

[mbiebl]

Yeah, unfortunately the Debian repository is still tarball based and I'm aware of the shortcomings of git archive / github snapshots.
So, I would prefer official release tarballs, but if it's too much effort, then Debian will certainly cope.

[mbiebl]

Btw, nice to see the @avahi project being in place now!

[mbiebl]

I staged those changes for now:

diff --git a/debian/watch b/debian/watch
index fbfcf52d..f0c0dce5 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
 version=4
-https://avahi.org/download/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
+opts="searchmode=plain" \
+  https://api.github.com/repos/avahi/@PACKAGE@/releases \
+  https://github.com/avahi/@PACKAGE@/releases/download/v(?:\d[\d.]*)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

This assumes that there will still be releases going forward.

[lathiat]

I think publishing release tarballs is still fine, you can upload them to the GitHub release no problem. Is there a best practice other projects have moved towards to continue or avoid doing that?

If we wanted to stop there'd be a bit of work to do I think since the make dist generates some outputs such as teh docs, autoconf, etc.

[evverx]

Is there a best practice other projects have moved towards to continue or avoid doing that?

I think it depends on the project. Some projects like systemd release git snapshots but it isn't exactly friendly to distros consuming tarballs (partly because those autogenerated snapshots can't be signed).

FWIW I agree that it would be better to keep releasing "make dist" tarballs.

(I don't think they should be kept in two different places though in the sense that I don't think the "download" folder at avahi.org is needed any more)

[mbiebl]

Let me clarify, that Debian does not depend on pre-generated files in the (dist) tarball.

What we would like to have though is a stable reference to the upstream tarball (bit-by-bit idential with the same hashsum).
My understanding is, that GitHub generates the tarballs for tags on the fly with no guarantees regarding reproducibility.