Nicholas D Steeves <s...@debian.org> writes: > Manphiz <manp...@gmail.com> writes: > >> Sean Whitton <spwhit...@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 >
Hi 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? -- Manphiz
signature.asc
Description: PGP signature
