Subject: bug#71924: 31.0.50; elpa.gnu.org has misleading link to bbdb source code

From: Stefan Monnier <[email-masked]>
Date: Sat, 08 Mar 2025 14:27:33 -0500

Hi Jules,

> * Problem
>
> The `bbdb` package is defined in elpa as pulling from nongnu elpa.
> This can be seen here -
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages?h=main#n89

Not exactly: it's pulling from the "nongnu.org" part of Savannah because
it is hosted and developed there (instead of, say, Codeberg).
I.e. BBDB is a "nongnu package" in the sense that, while it's hosted
on infrastructure provided by the GNU project, it is not officially part
of the GNU project (contrary to Emacs, say).

That's not to be confused with NonGNU ELPA, which is a distribution site
for Emacs packages.  The two are related, admittedly.  Also since all
packages distributed via GNU ELPA (such as BBDB) are considered as being
"somewhat part of Emacs", that means BBDB is both a "nongnu
project" and "part of a GNU project".
In practice, this doesn't matter very much.

> However the link to `bbdb`'s source code from the elpa website
> (http://elpa.gnu.org/packages/bbdb.html) points to the gnu elpa version
> of the source code:
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/?h=externals/bbdb.

And that's the right link in the sense that this is the code used to
build the tarball that's distributed on GNU ELPA.

> This causes confusion because the website does not point to the true
> source code that would be installed.

The code over at `nongnu.org` is closely related, and is indeed the
"upstream" of the code in `elpa.git`, but is not exactly "the true
source code that would be installed".

Clearly, the current setup is not ideal.  It's the result of the usual
historical accidents.  It would be desirable to fix it by
aligning/merging the `nongnu.org` code and the `elpa.git` code, e.g. so
that `elpa.gnu.org` can automatically pull changes from `nongnu.org`
rather than relying on explicit pushes by BBDB's maintainers.

But it also comes with its downsides (e.g. extra work in the short
term), which is why we settled on this setup.  This said, time has
passed and maybe the tradeoffs have changed now (AUCTeX was using
a similar organization for similar historical reasons and has recently
bit the bullet), so it's probably a good idea to take another look
at it.

Roland, what do you think?

        Stefan