Ulrich Mueller <u...@gentoo.org> wrote: > > I think the conclusion is that github generates tarballs on the fly, > and therefore we cannot rely on them being invariant over a long time.
Yes, but with emphasis on _long_ time and theory. In practice this was happening now exactly _once_ in a decade (according to all we learnt so far) for the understandable reason of fixing an annoying incompatibility in an exotic case. And the existence of zopfli shows that other backward-compatible improvements _would_ have been possible, but apparently non-changing of the produced tarball was always rated higher than anything else (up to this exception). So I would not worry too much about it: It is not worth the cost of hosting a huge number of tarballs permanently (or to convince upstream to let them be hosted by github for every single version, only because one cannot theoretically exclude that a similar thing won't ever happen again). Yes, for the transition period (until all github servers use a new enough version) a solution for the few involved tarballs has to be found (like temporarily hosting on devspace). But after this period it is only a question of updating the checksum once for the involved packages.
