Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

From: Gregory Heytings <[email-masked]>
Date: Tue, 11 May 2021 17:00:46 +0000

>>> Yes if you want the native compiler to be able to compile files, 
>>> otherwise you should either native compile all lisp files Ahead of 
>>> Time or set `comp-deferred-compilation' to nil in early init so that 
>>> Emacs will not try to native compile bytecode being loaded.
>>
>> That's helpful. Thanks.
>
> Note that if you will be distributing the *.eln files, I think the GPL 
> requires you to make the *.el files available.  In fact, this is so even 
> with the *.elc files.  So I'm not sure I understand how you could 
> distribute only the *.elc files until now: isn't that contrary to GPL?
>

Why would that be contrary to the GPL?  The *.el files are available on 
Debian and Debian-derived distrbutions, but Debian has chosen to make the 
distribution of Emacs more modular, and each "logical part" of Emacs is 
packaged separately:

- the emacs package (which is "a metapackage that will always depend on 
the latest recommended Emacs variant") depends on emacs-gtk or emacs-lucid 
or emacs-nox (= terminal-only)

- the emacs-gtk, emacs-lucid and emacs-nox packages (which contain the 
Emacs binary and corresponding pdmp files) all depend on on 
emacs-bin-common and emacs-common, and suggest emacs-common-non-dfsg

- the emacs-bin-common package (which contains the ctags, ebrowse, 
emacsclient, etags, hexl and rcs2log binaries) depends on emacs-common

- the emacs-common package (which contains the etc/ directory and the elc 
files) recommends emacs-el and suggests emacs-common-non-dfsg

- the emacs-el package contains the el files

- the emacs-common-non-dfsg contains the info files