Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#985459: dh-elpa: install error when root user has packages under /root/.emacs.d/elpa

13 views
Skip to first unread message

Nick Gasson

unread,
Mar 18, 2021, 10:50:03 AM3/18/21
to
Package: dh-elpa-helper
Version: 2.0.8
Severity: normal

Dear Maintainer,

I got this cryptic error when I installed elpa-company on a machine
where the root user had elpa packages already installed under
/root/.emacs.d/elpa:

Setting up elpa-company (0.9.13-2) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-company for emacs
install/company-0.9.13: Handling install of emacsen flavor emacs
install/company-0.9.13: byte-compiling for emacs

In toplevel form:
async-tests.el:22:1:Error: Cannot open load file: No such file or directory, company-tests

[... snip many similar errors ...]

In toplevel form:
template-tests.el:22:1:Error: Cannot open load file: No such file or directory, company-tests

In toplevel form:
transformers-tests.el:22:1:Error: Cannot open load file: No such file or directory, company-tests
ERROR: install script from elpa-company package failed
dpkg: error processing package elpa-company (--configure):
installed elpa-company package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
elpa-company
E: Sub-process /usr/bin/dpkg returned an error code (1)


The problem seems to be that it picks up the root user's local company
package from package-user-dir in preference to the Debian package in
package-directory-list.

The patch below overrides package-user-dir to point at the Debian elpa
source directory. Not sure if there's a better way to fix this but it
resolves the problem for me and seems more robust.


Index: dh-elpa-2.0.8/helper/install
===================================================================
--- dh-elpa-2.0.8.orig/helper/install
+++ dh-elpa-2.0.8/helper/install
@@ -51,6 +51,7 @@ echo install/${ELPA_DIR}: byte-compiling
(cd ${elc_dir}
set +e
${FLAVOR} --quick --batch -l package \
+ --eval "(setq package-user-dir \"$src_dir\")" \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
-f package-initialize -f batch-byte-compile *.el > Install.log 2>&1
if test $? -ne 0


-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Sean Whitton

unread,
Mar 18, 2021, 2:40:04 PM3/18/21
to
Hello Nick,

On Thu 18 Mar 2021 at 10:25PM +08, Nick Gasson wrote:

> The problem seems to be that it picks up the root user's local company
> package from package-user-dir in preference to the Debian package in
> package-directory-list.
>
> The patch below overrides package-user-dir to point at the Debian elpa
> source directory. Not sure if there's a better way to fix this but it
> resolves the problem for me and seems more robust.

Thank you for the report. Can you test this patch, please?

diff --git a/helper/install b/helper/install
index 1a2eb8a..af93ee4 100755
--- a/helper/install
+++ b/helper/install
@@ -51,6 +51,8 @@ echo install/${ELPA_DIR}: byte-compiling for ${FLAVOR}
(cd ${elc_dir}
set +e
${FLAVOR} --quick --batch -l package \
+ --eval "(setq package-directory-list \
+ (delete package-user-dir package-directory-list))" \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
-f package-initialize -f batch-byte-compile *.el > Install.log 2>&1
if test $? -ne 0

--
Sean Whitton
signature.asc

Nick Gasson

unread,
Mar 18, 2021, 11:30:03 PM3/18/21
to
Hi Sean,

On 03/18/21 18:31 PM, Sean Whitton wrote:
>
> Thank you for the report. Can you test this patch, please?
>
> diff --git a/helper/install b/helper/install
> index 1a2eb8a..af93ee4 100755
> --- a/helper/install
> +++ b/helper/install
> @@ -51,6 +51,8 @@ echo install/${ELPA_DIR}: byte-compiling for ${FLAVOR}
> (cd ${elc_dir}
> set +e
> ${FLAVOR} --quick --batch -l package \
> + --eval "(setq package-directory-list \
> + (delete package-user-dir package-directory-list))" \
> --eval "(add-to-list 'package-directory-list \"$src_dir\")" \
> -f package-initialize -f batch-byte-compile *.el > Install.log 2>&1
> if test $? -ne 0

I've just tried this but unfortunately I get the same error. I think
it's because package-load-all-descriptors in package.el always cons-es
package-user-dir on the front of package-directory-list when it searches
for a package

(defun package-load-all-descriptors ()
...
(dolist (dir (cons package-user-dir package-directory-list))
(when (file-directory-p dir)
...)))

Perhaps an alternative is to set package-user-dir to a temporary
directory that's guaranteed not to contain any existing packages.

--
Thanks,
Nick

Sean Whitton

unread,
Mar 31, 2021, 8:00:05 PM3/31/21
to
Hello,
Yes, that sounds like a good idea.

--
Sean Whitton
signature.asc

David Bremner

unread,
Sep 16, 2021, 9:30:03 AM9/16/21
to
Nick Gasson <ni...@nickg.me.uk> writes:

> Hi Sean,
>
> On 03/18/21 18:31 PM, Sean Whitton wrote:
>>
>> Thank you for the report. Can you test this patch, please?
>>
>> diff --git a/helper/install b/helper/install
>> index 1a2eb8a..af93ee4 100755
>> --- a/helper/install
>> +++ b/helper/install
>> @@ -51,6 +51,8 @@ echo install/${ELPA_DIR}: byte-compiling for ${FLAVOR}
>> (cd ${elc_dir}
>> set +e
>> ${FLAVOR} --quick --batch -l package \
>> + --eval "(setq package-directory-list \
>> + (delete package-user-dir package-directory-list))" \
>> --eval "(add-to-list 'package-directory-list \"$src_dir\")" \
>> -f package-initialize -f batch-byte-compile *.el > Install.log 2>&1
>> if test $? -ne 0
>
> I've just tried this but unfortunately I get the same error. I think
> it's because package-load-all-descriptors in package.el always cons-es
> package-user-dir on the front of package-directory-list when it searches
> for a package

Setting user-package-dir to a nonexistent directory also seems to
work. Nick, can you try the dh-elpa version at
https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply

https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b

to /usr/lib/dh-elpa/helper/install

Some possible alternatives:

1) maybe Sean remembers the proposed convention for a known empty
directory? Is this usable in stable?

2) We could create and clean up an empty temporary directory

3) We could create /usr/lib/dh-elpa/empty

Nicholas D Steeves

unread,
Sep 16, 2021, 6:00:04 PM9/16/21
to
CCing #989905 (base-files)

> Setting user-package-dir to a nonexistent directory also seems to
> work. Nick, can you try the dh-elpa version at
> https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply
>
> https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b
>
> to /usr/lib/dh-elpa/helper/install
>

That's a cool low-friction solution! :-) P.S. How likely is a future
where Emacs will return non-zero exit status if package-user-dir is not
found? I'm guessing unlikely?

> Some possible alternatives:
>
> 1) maybe Sean remembers the proposed convention for a known empty
> directory? Is this usable in stable?
>
> 2) We could create and clean up an empty temporary directory
>
> 3) We could create /usr/lib/dh-elpa/empty

I have no strong opinion towards any of these options, but I was shocked
to discover that Debian didn't already have a /var/run/empty.

So I filed #989905 requesting /var/run/empty (present in Fedora, RedHat,
CentOS, SUSE, Arch, FreeBSD, and probably more). It's not FHS, but it
seems like maybe it should be; although, a systemd-centric future
probably dynamically creates empty paths as-needed...

https://bugs.debian.org/989905

Maybe a TC member could say something about whether a canonical empty
directory equivalent to /dev/null is good design? Unfortunately it
won't help the situation in stable--unless base-files receives a
stable-update. It seems like it might also require a point in Policy
along the lines of "packages must not install files nor write to
/var/run/empty".

#1 (via #989905) seems the cleanest, most standard, and conventional to
me, #2 seems like a maintscript (which are increasingly discouraged) or
a dpkg feature, and it seems to me that #3 sets a precedent that
sanctions the proliferation of empty directories (which is maybe
harmless and only kind of ugly and confusing?). It's possible I'm
biased, so I leave it to you!

Cheers,
Nicholas
signature.asc

David Bremner

unread,
Sep 17, 2021, 6:20:03 AM9/17/21
to
Nicholas D Steeves <st...@debian.org> writes:

> CCing #989905 (base-files)
>
>> Setting user-package-dir to a nonexistent directory also seems to
>> work. Nick, can you try the dh-elpa version at
>> https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply
>>
>> https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b
>>
>> to /usr/lib/dh-elpa/helper/install
>>
>
> That's a cool low-friction solution! :-) P.S. How likely is a future
> where Emacs will return non-zero exit status if package-user-dir is not
> found? I'm guessing unlikely?

Indeed that issue is why I mention the other possibilities. At least as
far as stable releases go, I think we'll have enough notice to change to
a different strategy if emacs gets fussier. Luckily with the newer
dh-elpa setup we don't need to do any elpa-* package rebuilds to change
those scripts.

Nick Gasson

unread,
Sep 19, 2021, 11:10:05 AM9/19/21
to
Hi David,

On 16/09/21 21:23 pm, David Bremner wrote:
>
> Setting user-package-dir to a nonexistent directory also seems to
> work. Nick, can you try the dh-elpa version at
> https://salsa.debian.org/emacsen-team/dh-elpa ?
>

I've just tested this and can't reproduce the error any more, thanks!

--
Nick
0 new messages