>>>> Let me know if you can easily source tarballs from ELPA. If not, we can
>>>> try to come up with something easier for distro maintainers.
>>>
>>> Unfortunately, this doesn't play well with Gentoo's workflow. We cannot
>>> use the uncompressed tarball because it will be gone for older releases
>>> (which may be the release in our stable distro tree), and the compressed
>>> tarball doesn't yet exist when we add an ebuild for the newest release.
>>>
>>> An additional compressed tarball also for the newest release would fix
>>> this problem for us.
>
> Technically this should be easy to adjust; the only question we have to
> clarify is why this is the current behaviour.
I definitely don't want to keep the old tarballs in an uncompressed
format, since it's absurdly inefficient (in disk space, network
bandwidth, and/or CPU time).
But if it can make things easier, we could have both the uncompressed
`.tar` and its compressed version (rather than wait until the next
release before generating it).
We sadly need the uncompressed version because that's how the ELPA
protocol was defined (and that was in large part due to the fact that
we can't/couldn't easily rely on the existence of a standard
decompressor like `gunzip` on every client machine).
>>> We'd also prefer a more common format, e.g. xz instead of lzip (which
>>> isn't supported by our standard unpacker), but this is a minor issue.
> This might also be difficult due to storage issues.
I find `lzip` to be much better behaved (which probably just means "more
like the other tools with which I'm familiar"), which is why I chose it.
I think it's also a bit closer philosophically to GNU.
In terms of storage, it should make no difference: `xz` and `lz` files
use the exact same compression algorithm.
>> It sounds reasonable to produce compressed tarballs for the latest
>> package releases in addition to uncompressed.
Agreed.
>> Also, I am wondering about the policy for keeping the older
>> tarballs. This may be important information for distros that keep older
>> versions available for a long time.
> It is capped to the 20 most recent tarballs.
It's more complicated than that. We use a heuristic based on version
numbers that tries to keep the "most important" tarballs.
E.g. we might keep versions 19.7, 20.1.5, and 20.2.7 and
throw away versions 20.2.6 and 20.1.4.
Also, we keep tarballs at least 2 years (which means we sometimes keep
more than 20 tarballs for a given package).
> If it is of any use, distributions can also clone checkouts of any
> package-branch directly from elpa.git/nongnu.git if they have commit ID.
Indeed, if you want releases to exist in the long run, that's
probably a better option, tho it may require extra work to build some of
the contents of the tarball, like the `<PKG>-pkg.el` file.
Stefan
