[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
David Bremner |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Fri, 30 Sep 2022 10:13:56 -0300 |
> The reason stated by Rob was that they want to prevent "writing to
> user's HOME directory". I don't think I understand the rationale well
> enough, and I asked some questions about it. I hope Rob will answer,
> and then we could continue discussing what is reasonable for that use
> case.
For package builds, Debian has the following policy
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
in particular
Required targets must not attempt to write outside of the unpacked
source package tree. There are two exceptions. Firstly, the binary
targets may write the binary packages to the parent directory of the
unpacked source package tree. Secondly, required targets may write
to /tmp, /var/tmp and to the directory specified by the TMPDIR
environment variable, but must not depend on the contents of any of
these.
This restriction is intended to prevent source package builds
creating and depending on state outside of themselves, thus
affecting multiple independent rebuilds. In particular, the required
targets must not attempt to write into HOME.
Some additional byte compilation happens at package install time. In my
view the same restrictions should apply there. In addition to the
unintentional sharing of state mentioned in policy, there is also the
issue of cleaning up after a package on uninstall. This is manageable
now because any generated .elc files go in a package specific directory,
which can just be removed on purging the package.
I think just turning off native compilation when HOME is not writeable
would be sensible from a Debian point of view. Emacs did not previously
require a writable HOME (although maybe most users never tested
this). It would be unfortunate if this changed for Emacs with native
compilation support.
David
PS. Please CC me on any replies (that you want me to read). I'm not
subscribed to the list.
PPS. This reply is synthesized from "reply via email" on the archive
page. Apologies in advance for any list etiquette failures.
- Re: Suppressing native compilation (short and long term), (continued)
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/09/28
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/28
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/09/28
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/28
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/09/28
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/29
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/09/29
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/29
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/09/29
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/29
Re: Suppressing native compilation (short and long term),
David Bremner <=
Re: Suppressing native compilation (short and long term), David Bremner, 2022/09/30
Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/09/30
Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/09/30