Bug#1137368: Missing dependency on elpa-emacsql-sqlite

Sean Whitton <[email protected]> Thu, 04 Jun 2026 15:29:08 +0100

Newsgroups	gmane.linux.debian.devel.emacsen
Message-ID	<87ik7ypeff.fsf__19369.4181901932$1780584102$gmane$org@melete.silentflame.com>

Xiyue Deng [04/Jun  2:24am -07] wrote:
> Control: severity 1138783 serious
> Control: reassign 1137368 src:emacsql
> Control: reassign 1138783 src:emacsql
> Control: merge 1137368 1138783
>
> I took the privilege to reassign both Bug#1137368 and Bug#1138783 to
> src:emacsql. I think the root cause of both issues is that the
> elpa-emacsql package only contains the high-level interface without any
> actual backend, so it cannot do much by itself. The package description
> says: "EmacSQL is a high-level Emacs Lisp front-end for SQLite". So it
> is expected that by installing elpa-emacsql it should provide the sqlite
> backend at least.
>
> Currently, the 3 backend packages, elpa-emacsql-{sqlite,mysql,psql},
> depend on elpa-emacsql. This prevents elpa-emacsql from depending on
> elpa-emacsql-sqlite, which will introduce a circular dependency.
> Reversing the dependency is also wrong, as elpa-emacsql-sqlite by itself
> won't work without the support of elpa-emacsql. The same goes for other
> backends. In this case, separating the backends inherently causes
> circular dependencies for things to work.
>
> I believe in this case the separation of backends complicates the
> handling with minimal gain: packages depending on emacsql by ELPA
> convention need to be patched to depend on emacsql-sqlite (like case in
> elpa-closql and org-roam), and the space saving is really not worth it -
> all 3 backends code is less than 40kb combined.
>
> Therefore, I'd like to propose merging back all *.el back to
> elpa-emacsql and make all backend packages dummy, which would solve all
> the issues mentioned above.
>
> CCing Sean who did the initial packaging with separate backends and
> the current maintainer Aymeric for comments. I will proceed with the
> implementation once the plan is approved.

This would mean that the elpa-* package names would no longer correspond
to the upstream ELPA packages, right?  Are there no alternatives?

-- 
Sean Whitton

signature.asc (application/pgp-signature, 869 B)