[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
Eli Zaretskii |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Fri, 30 Sep 2022 16:56:56 +0300 |
> From: David Bremner <david@tethera.net>
> Cc: emacs-devel@gnu.org, akrl@sdf.org, rlb@defaultvalue.org
> 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.
This is what I'm asking about: what exactly triggers the compilation?
Just installing a package shouldn't do that, only loading it into
Emacs should.
The other part of what I asked is that if for some reason installation
does need to compile files (something that I still need to understand
why it happens), there's nothing that hard-codes HOME in the directory
list used for that. You can set native-comp-eln-load-path to anything
you want, and only the directories in that list will be used.
> 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.
See above: you can do the same with *.eln files, if, for some reason,
they are produced by the installation.
> 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.
Emacs doesn't require a writable HOME, it requires a writable
directory to store *.eln files. It doesn't have to be HOME. And once
again, I still don't understand why *.eln files are produced at
installation time in the first place.
- Re: Suppressing native compilation (short and long term), (continued)
- 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, 2022/09/30
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