While practicing some Emacsen packaging and getting assistance from #debian-mentors, I noticed that with "debhelper-compat (=13)" it now
sets up a writable $HOME[1]. With this, Emacs with native compilation doesn't need any specially handling during build or test anymore, at
least in dh_auto_*. However, currently dh-elpa doesn't use the same set
up as dh_auto_*[2] yet, so currently it will still cause failure in
targets like dh_elpa_test. Will the team consider to follow the same convention so that $HOME becomes writable? I assume this will also make
it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
related patches.
Hello,
On Wed 09 Aug 2023 at 02:23pm -07, Manphiz wrote:
While practicing some Emacsen packaging and getting assistance from
#debian-mentors, I noticed that with "debhelper-compat (=13)" it now
sets up a writable $HOME[1]. With this, Emacs with native compilation
doesn't need any specially handling during build or test anymore, at
least in dh_auto_*. However, currently dh-elpa doesn't use the same set
up as dh_auto_*[2] yet, so currently it will still cause failure in
targets like dh_elpa_test. Will the team consider to follow the same
convention so that $HOME becomes writable? I assume this will also make
it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
related patches.
Debian Policy requires that package builds don't attempt to write into HOME.
Sean Whitton <spwhitton@spwhitton.name> writes:
Hello,
On Wed 09 Aug 2023 at 02:23pm -07, Manphiz wrote:
While practicing some Emacsen packaging and getting assistance from
#debian-mentors, I noticed that with "debhelper-compat (=13)" it now
sets up a writable $HOME[1]. With this, Emacs with native compilation
doesn't need any specially handling during build or test anymore, at
least in dh_auto_*. However, currently dh-elpa doesn't use the same set >>> up as dh_auto_*[2] yet, so currently it will still cause failure in
targets like dh_elpa_test. Will the team consider to follow the same
convention so that $HOME becomes writable? I assume this will also make >>> it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
related patches.
Debian Policy requires that package builds don't attempt to write into HOME.
Indeed, found the item in section 4.9[1]. Though I do wonder what is
the reason that compat 13 starts to provide a writeable $HOME?
[1] https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles
Sean Whitton <spwhitton@spwhitton.name> writes:
On Wed 09 Aug 2023 at 02:23pm -07, Manphiz wrote:
While practicing some Emacsen packaging and getting assistance from
#debian-mentors, I noticed that with "debhelper-compat (=13)" it now
sets up a writable $HOME[1]. With this, Emacs with native compilation
doesn't need any specially handling during build or test anymore, at
least in dh_auto_*. However, currently dh-elpa doesn't use the same set >>> up as dh_auto_*[2] yet, so currently it will still cause failure in
targets like dh_elpa_test. Will the team consider to follow the same
convention so that $HOME becomes writable? I assume this will also make >>> it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
related patches.
Debian Policy requires that package builds don't attempt to write into HOME.
Indeed, found the item in section 4.9[1]. Though I do wonder what is
the reason that compat 13 starts to provide a writeable $HOME?
[1] https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles
Manphiz <manphiz@gmail.com> writes:
Sean Whitton <spwhitton@spwhitton.name> writes:
On Wed 09 Aug 2023 at 02:23pm -07, Manphiz wrote:
While practicing some Emacsen packaging and getting assistance from
#debian-mentors, I noticed that with "debhelper-compat (=13)" it now
sets up a writable $HOME[1]. With this, Emacs with native compilation >>>> doesn't need any specially handling during build or test anymore, at
least in dh_auto_*. However, currently dh-elpa doesn't use the same set >>>> up as dh_auto_*[2] yet, so currently it will still cause failure in
targets like dh_elpa_test. Will the team consider to follow the same
convention so that $HOME becomes writable? I assume this will also make >>>> it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
related patches.
Debian Policy requires that package builds don't attempt to write into HOME.
Indeed, found the item in section 4.9[1]. Though I do wonder what is
the reason that compat 13 starts to provide a writeable $HOME?
[1] https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles
https://bugs.debian.org/942111
https://bugs.debian.org/933799
Please note several pitfalls. One question I have after reading these is:
Shouldn't Emacs itself gracefully handle an unset, nonexistent, or
read-only $HOME gracefully?
Cheers,
Nicholas
Thanks for the pointers! I think the reasons given in the bugs are essentially the same as the scenarios I gave in my other mail,
especially when it is not Emacs itself but the client code that accesses $HOME. Would the team consider enabling it in dh-elpa given that no
write is done to $HOME/$XDG_* so that no Policy violation happens?
And I forgot to provide more context on having dh-elpa provide a "$HOME"
(not necessarily writable), so here it is: while practicing elpa-ifying auctex, I found that it tried to access "$HOME" even though native compilation was turned off by default in dh-elpa. Turns out it sets the "default-directory" to "$HOME" to cope with an evince issue[1]. So
during byte-compiling it will try to set $CWD to $HOME, but it will not actually write anything (so no Debian Policy violation). With compat 13
it passes the dh_auto_build phase but fails in dh_elpa_test as the
latter doesn't set up $HOME in the same way.
Though not a common practice (yet), it seems having a usable $HOME is expected for some field usage, and providing a similar set up in dh-elpa
may help in such cases.
[1] https://git.savannah.gnu.org/cgit/auctex.git/commit/?id=fa309c9559f0a6dc3428daca6896f615e7030521
Shouldn't Emacs itself gracefully handle an unset, nonexistent, or
read-only $HOME gracefully?
Hello,
On Thu 10 Aug 2023 at 01:11pm -07, Manphiz wrote:
Thanks for the pointers! I think the reasons given in the bugs are
essentially the same as the scenarios I gave in my other mail,
especially when it is not Emacs itself but the client code that accesses
$HOME. Would the team consider enabling it in dh-elpa given that no
write is done to $HOME/$XDG_* so that no Policy violation happens?
There's the risk of bugs here. Setting HOME to /nonexistent ensures
that unknown writing to HOME doesn't slip in in a future upload.
Sean Whitton <spwhitton@spwhitton.name> writes:
Debian Policy requires that package builds don't attempt to write into HOME.
Indeed, found the item in section 4.9[1]. Though I do wonder what is
the reason that compat 13 starts to provide a writeable $HOME?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:59:19 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,117 |