emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suppressing native compilation (short and long term)


From: Stefan Monnier
Subject: Re: Suppressing native compilation (short and long term)
Date: Sun, 02 Oct 2022 13:13:59 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> Which part of the "emacs+magit" package is the "binary package"?

The "binary" Debian package for `elpa-magit` mostly contains Magit's
`.el` files plus the doc and a few other things.  IOW it's fairly
similar to our ELPA tarballs.

So it's very close to the source code itself, but it's still separate
from "the source" (which you can get via things like `apt source elpa-magit`
and will fetch some tarball rather than a `.deb` file) from which the
`.deb` is built.

> And if we are talking about Magit in this example, then how come its
> being bundled to Emacs change anything of what I said?

I don't think there's a `emacs+magit` package in Debian.  There's an
`elpa-magit` package and an `emacs` package.

>> For the record: I personally know of situations where such a setup
>> would like to use native-comp and would very much prefer NOT to
>> duplicate either the eln files per-user nor the effort of creating
>> such. Whether or not that situation is important enough to the
>> combination of emacs-devel and debian-maintainers to justify effort
>> on either side is, of course, debatable, but I am highly confident
>> that they exist (at least, did before the pandemic).
>
> Please forgive me, but you cannot expect us to regard such situations
> seriously as long as you don't describe them.

We don't have to take their opinion into account when choosing
Emacs's defaults.  We just need to provide the tools that let them get
the behavior they want.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]