bug#63916: 30.0.50; use-package: changes do not propagate to elpa-devel

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But if I disable sandboxing, then it works.  The issue appears to be
>> that the files under package/use-package are linked in using symlinks,
>> but the directory (the emacs checkout) that is being linked to is not
>> exposed via bwarp.  If I add that to the ro-binds, then I can build the
>> package.  This diff might be enough to resolve the issue:
>>
>> diff --git a/elpa-admin.el b/elpa-admin.el
>> index 24dd16d3cb..81467aa628 100644
>> --- a/elpa-admin.el
>> +++ b/elpa-admin.el
>> @@ -1262,7 +1262,8 @@ The INFILE and DISPLAY arguments are fixed as nil."
>>      "--tmpfs" "/tmp"))
>>  
>>  (defvar elpaa--sandbox-ro-binds
>> -  '("/lib" "/lib64" "/bin" "/usr" "/etc/alternatives" "/etc/emacs" "/gnu"))
>> +  `("/lib" "/lib64" "/bin" "/usr" "/etc/alternatives" "/etc/emacs" "/gnu"
>> +    ,(file-truename (expand-file-name "emacs"))))
> [...]
>> CC: Stefan, does this look OK to you?
>
> Building of :core packages outside of `elpa.gnu.org` is indeed tested on
> very lightly.  In `elpa.gnu.org`, the `emacs` subdirectory is not
> a symlink so we avoid that problem.

OK, I forgot that I added the symlink.

> The above patch feels a bit hackish because it depends on the
> directory that happens to be current when the file is loaded.

I agree, that could be made more robust but isn't elpa-admin.el always
invoked via make?

> BTW, you should be able to make the current code work without changing
> it, by adding
>
>     (sandbox-extra-ro-dirs "/where/ever/your/emacs/source/dir/is")
>
> to the `elpa-config` file.

Of course, that was my first idea but I wanted to find a solution that
wouldn't require every user to manually configure this, since the error
message does not make it obvious what went wrong.

>
>         Stefan
>

-- 
Philip Kaludercic