Possible packaging issue causing problems for elfeed

[kelleyk]

As reported by @alphapapa in skeeto/elfeed#279. (This is a placeholder while I read/investigate.)

[kelleyk]

From the EmacsWiki:

On GNU/Linux, the default value of ‘load-path’ includes two special directories and their descendants: /usr/local/share/emacs/VERSION/site-lisp and /usr/local/share/emacs/site-lisp. The first directory contains packages for a particular Emacs version; the second contains packages for all installed versions of Emacs. These directories contain files for the current site, for use by the system administrator when installing software locally[1].

On my 16.04 LTS system, the Ubuntu packages for Emacs 24.x also install files to /usr/local/share/emacs24, but the Emacs 25.x packages from my PPA do not seem to have created anything in /usr/local/share/emacs25. These paths aren't mentioned above--perhaps they're a change made by Debian/Ubuntu maintainers in order to allow multiple versions to exist alongside one another?

$ find /usr/share/emacs* -iname subdirs.el | xargs -n1 dpkg -S
emacs25-common: /usr/share/emacs/site-lisp/subdirs.el
emacs24-common: /usr/share/emacs/24.5/lisp/subdirs.el
emacs25-common: /usr/share/emacs/25.3/lisp/subdirs.el
emacs25-common: /usr/share/emacs/25.3/site-lisp/subdirs.el
emacs24-common: /usr/share/emacs24/site-lisp/subdirs.el

[kelleyk]

My packaging was originally based on the emacs-snapshot PPA, and not the Debian/Ubuntu packaging, which seems to be the source of the discrepancy.

There are some references in that packaging's debian/rules to what they call flavor. (This is from the emacs24 source package in 16.04.)

...
 72 # The flavor (i.e. emacs21) currently matches the source package name.
 73 flavor := $(src_name)
...
424      # lisp path directories
425      install -d $(pkgdir_common)/etc/$(flavor)/site-start.d
426      install -d $(pkgdir_common)/usr/share/$(flavor)
427
428      # The version-specific site-lisp dir, say emacs/21.1/site-lisp, needs
429      # to be in share/FLAVOR so that as we upgrade from 21.1 to 21.2,
430      # etc., add-on package bits don't get left behind.
431      mv $(pkgdir_common)/usr/share/emacs/$(runtime_ver)/site-lisp \
432          $(pkgdir_common)/usr/share/$(flavor)
433      dh_link -p$(flavor)-common usr/share/$(flavor)/site-lisp \
434              usr/share/emacs/$(runtime_ver)/site-lisp
435
436      # This is a duplicate of the file in FLAVOR/site-lisp
437      rm $(pkgdir_common)/usr/share/emacs/site-lisp/subdirs.el
...

[kelleyk]

Thank you, @alphapapa, for the careful investigation and for mentioning me in that beautifully-written issue so that I could take a look.

I'm a little bit busy at the moment, but when I have the time, I will take a look at modifying my packaging so that it installs these things into (and loads them from) e.g. /usr/share/emacs26 instead of /usr/share/emacs; this should resolve the problem that you are seeing. Apologies for the trouble!

[alphapapa]

I'm glad it was helpful. No apologies necessary, I appreciate your work on the packaging!

[kelleyk]

On 20.04, the Ubuntu-provided packages for Emacs 26.3 have the following load-path:

/usr/local/share/emacs/26.3/site-lisp
/usr/local/share/emacs/site-lisp
/usr/share/emacs/26.3/site-lisp
/usr/share/emacs/site-lisp
/usr/share/emacs/26.3/lisp
/usr/share/emacs/26.3/lisp/[many subdirs]

My emacs27 packages (which should be available in the PPA shortly) have been updated to use the same configuration; when I install them on a test system, I see the following load-path:

/usr/local/share/emacs/27.1/site-lisp
/usr/local/share/emacs/site-lisp
/usr/share/emacs/27.1/site-lisp
/usr/share/emacs/site-lisp
/usr/share/emacs/27.1/lisp
/usr/share/emacs/27.1/lisp/[many subdirs]

Hopefully this resolves the issue going forward. Does anyone have feelings either way about going back and releasing updated packages for Emacs 25 and 26 that do the same thing? I'm not sure that it's particularly worth the effort, and it would also mean that people who depend on the old behavior would get a little surprise.

[alphapapa]

Thanks, Kevin! Your service to the Emacs community is valuable and appreciated.