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: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Sun, 02 Oct 2022 21:54:35 +0300

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 13:35:33 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, I don't think the similar handling makes sense here.  The *.elc
> > files are architecture- and configuration-independent, whereas the
> > *.eln files are not.  E.g., the same foo.elc could be used by user A
> > who runs Emacs 28 and by user B who runs Emacs 29.  But the
> > corresponding *.eln files will be different, even though they were
> > produced from the same foo.el.
> 
> Right, but for what it's worth, the Debian infrastructure is already set
> up to, and would, maintain separate .eln files/trees for those two
> cases, *if* we ever re-versioned the emacs packages.

Alas, there are many more than just two cases!

> Right now, there's only one GNU Emacs flavor in debian, we don't provide
> versioned packages/flavors like emacs27 and emacs28 anymore.

But a user who installs Emacs 28 doesn't need to nuke the Emacs 27
installation, does he?

And the same with a user who wants both emacs-nox, emacs-pgtk, and
emacs-lucid (say) installed on the same system.  Right?



reply via email to

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