Re: history of ELPA packages and dependencies (was: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot))

[Lynn Winebarger]

On Wed, Apr 19, 2023 at 6:51 PM Lynn Winebarger <owinebar@gmail.com> wrote:
> The "delta" of the package set installed
> in the user area has to be enough to make the set of libraries "seen"
> by the user coherent.  That is, say package A and B both depend on
> package C and all are in the site-level packaging area.  Then the user
> wants a different version of package A, which requires a different
> version of package C.  Coherence means that if the version of package
> B installed at the site level is incompatible with the desired version
> of package C, then a compatible version of package B will also have to
> be installed in the user packaging area.  That set has to be
> transitively closed.

Calculating the set of sets of package/version pairs satsifying the
"coherence" constraint requires a lot of data from each published
version of each package in an ELPA.

Looking at the Savannah repos for GNU/nonGNU ELPAs, some package
branches appear to have multiple elisp files with package header
fields.  For example, externals/corfu in the GNU ELPA repo has a
subdirectory "extensions" in which some elisp files appear to contain
package definitions.  However, the GNU ELPA only has one "corfu"
package.  Unfortunately, I can't tell from that example if elpa-admin
completely ignores the package-requires in the other elisp files, or
determines the set of requirements based on fields from all included
elisp files.

So, can I determine package-requires of each package commit by looking
only at the main elisp file for the package after checking out that
commit?

I'm sure MELPA will be more challenging, but building a history for
GNU/nonGNU ELPA packages will be a good starting point.

Thanks,
Lynn