bug#46441: GNU ELPA feature request: host .lz archives (as well as uncompressed) for current versions

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Thanks for the reply! The particular use case here is to have a
> reproducible environment via the Nix package manager.

I see, yes that makes sense.  Hmm...

> months, it's fair to say a "year's worth" of stability would reduce
> user-facing problems to almost zero -- and I guess archiving 20 releases
> provides that with room to spare.

Actually, 20 is not necessarily that generous in this regard: it's 20
total, but we try to preserve "key" releases (e.g. the ones where the
leading number increased and the ones just before that) rather than
focus only on the most recent ones.  So if the latest version is 6.7,
it's quite possible that 6.4 came out fairly recently but has already
been pruned because we preferred to keep some older ones instead.

If you can work from the elpa.git instead, then you'll avoid those
problems (but the content is slightly different, so it might be less
convenient).

> If it's possible to do this for any package, then this is a great
> alternative! I see there's an elpa-packages file in the ELPA Git repo
> pointing to the sources for each package, which is definitely a format
> that Nix can work with. A few questions, just to be sure:

The URL just points to the "expected" upstream location.  The GNU ELPA
packages are never built from the data at that URL but from the (more or
less) copies we keep in the branches in `elpa.git`.

> 1) When does a commit to the package's repo generate a new release on
> ELPA? (every commit triggers a release?)

When the commit changes the `Version:` header in the main file.

> 2) Are there "exceptions" to the list in elpa-packages? That is, if a
> package's repo is listed nil in elpa-packages, is it guaranteed that a
> branch will exist for that package in ELPA's Git repo?

Regardless of the `:url`, the package's code is kept in the
corresponding `externals/[PKGNAME]` branch.


        Stefan