Re: Suppressing native compilation (short and long term)

[Rob Browning <rlb@defaultvalue.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm still discussing with Rob his needs.  I hope to eventually
> understand their needs.  For now my only conclusion is that they need
> to tweak native-comp-eln-load-path in some situations, to control
> where the *.eln files are deposited.  Which is easy and supported
> already, AFAIU.

Eli, Lars, Andrea, and others, I think I'm mostly caught back up with
this thread, and hope to summarize a few things here:

  - I made a mistake in emphasizing (via the thread subject) a
    particular "solution" (suppressing native compilation).  In the end,
    from the Debian perspective, for the most immedate issue, we don't
    need that particular solution (and I wasn't actually set on it at
    the time).  I'd mostly started there because it's *a* possible
    solution, and one I'd imagined might be easyish to implement
    (clearly that was naive).  But other solutions would be fine too.

  - For example, redirecting all incidental writes away from HOME would
    be fine too.

  - We'd prefer to still be able to set HOME=/does-not-exist, which I
    assume would mean that we'd need some other way to redirect *all* of
    the eln file writes (including trampolines).

    Our practice of setting HOME to a nonexistent directory during some
    packaging operations allows us to detect unexpected, and erroneous
    attempts to write to HOME during those processes.

  - If we are going to have "some other way" to redirect the eln files,
    then for us an environment variable might be easier, so that we can
    just export it before we start the relevant build/test/etc. and then
    it'll affect all invocations of emacs in that environment.  I
    suspect an environment variable might also make it easier to
    establish the setting "early enough" in the emacs startup process,
    but don't know that.

  - If just setting HOME will do the job, and there's no interest here
    in anything further, then we can probably just do that, or if we
    ended up needing to, we could likely add our own
    DEBIAN_... environment variable, and carry a patch, but of course
    that's less desirable.

  - As an aside, I suspect Emacs may eventually want to have some way to
    restore the ability to tolerate an unwritable filesystem.  I have
    more than once in the past launched emacs from an emergency shell to
    fix a broken host where the filesystem was read-only and /home might
    not be mounted (and if it were on NFS and there's no network yet,
    could not be).

    I'd much rather use emacs there, than /usr/bin/sensible-editor.  Of
    course now I know that I could just set HOME=/tmp and proceed, but
    will others?  Might at least be worth making sure any error messages
    would lead people to that option.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4