Re: Suppressing native compilation (short and long term)

[Rob Browning <rlb@defaultvalue.org>]

chad <yandros@gmail.com> writes:

> At the risk of over-explaining due to message crossing mid-flight: the
> thing you might be missing is that Debian provides a mechanism for people
> to install *.elc files in a space shared by all users that is not
> writable by those users, and there are people that use this provision.
> Since these are used for *.elc files, it seems highly likely that they will
> be desired for *.eln files.

To be clear, I think there are (at least) two concerns here.

First, from the Debian side, we may need some way to avoid writing files
(i.e. the .eln files) to certain locations during testing, installs,
etc.  That problem may be solved -- via the variable that's already been
mentioned.

Though note that for reasons we can elaborate on if desired, it might be
easier for us if the default for that variable could also be set via a
corresponding environment variable, but that's a separate question.

(For example, we have relevant emacs-related packages where the upstream
 build process runs emacs a level or two "down" (subprocess-wise), and
 so it'd be a lot less invasive if we could just set an environment
 variable to change the .eln destination, instead of having to figure
 out how to change each invocation of emacs in that package (and
 maintain those changes across future upstream versions).


A second, and a separable question, is whether Debian should try to
maintain system-level (root owned) .eln files the same way it does for
.elc files.

I consider that an open question, and it could well be that the answer
ends up being "no".  That's what we're trying to find out, and of course
we have to begin by trying to communicate why that might be desirable.

So here we are :)

It's certainly the case that if the consensus here (among the upstream
developers) is that we shouldn't do that, and that future
choices/changes aren't likely to take that use case into consideration,
then we have our answer.

And that's fine.  In the end, we just wanted to explain the potential
use case(s), and see how the developers felt about it.

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