Red Hat Bugzilla – Bug 484830
emacs-el files compressed a bit to far
Last modified: 2010-04-20 09:09:18 EDT
Description of problem:
With emacs-el files installed but corresponding .elc files "hidden", as I am not man enough to do debugging with compiled functions, an attempt to start emacs fails with:
OTOH with jka-compr.el and jka-cmpr-hook.el gunzipped emacs starts, and works with a debugger, just fine if somewhat slower.
Version-Release number of selected component (if applicable):
Possible that jka-cmpr-hook.el.gz can be left alone but I did not risk it.
(In reply to comment #0)
> Description of problem:
> With emacs-el files installed but corresponding .elc files "hidden"
how do you hide them?
> how do you hide them?
For example like that (with 'emacs-el' package installed):
find . -name '*.elc' | cpio -pmd /var/tmp/hide
find . -name '*.elc' | xargs rm
so later you can move them back.
That happens when you attempt to trace and/or debug some elisp code; possibly in something not supplied by Fedora. You still do not want a debugger to dive into byte-compiled fragments.
When you will do the above then trying to start emacs will bring you that:
Recursive load: "/usr/share/emacs/23.1/lisp/jka-compr.el.gz", "/usr/share/emacs/23.1/lisp/jka-compr.el.gz", "/usr/share/emacs/23.1/lisp/jka-compr.el.gz", "/usr/share/emacs/23.1/lisp/jka-compr.el.gz", "/usr/share/emacs/23.1/lisp/jka-compr.el.gz", "/usr/share/emacs/23.1/lisp/international/encoded-kb.el.gz"
A search through emacs-common-23.1-5.fc11 shows some 80 .el files which are not compressed but jka-compr.el.gz and jka-cmpr-hook.el.gz are not among those. A comment in jka-compr.el.gz says:
;; This package implements low-level support for reading, writing,
;; and loading compressed files.
so it is not that surprising that one gets "Recursive load". With those two uncompressed emacs configured as above starts without issues.
Yes, putting back jka-cmpr-hook.elc and jka-compr.elc allows to start here as well but one has to do some guesswork.
It appears that having not compressed jka-compr.el is enough. emacs then reports:
Personally I would advocate disabling the gzipping of the source .el files as the space saving really isn't worth the problems it's causing.
[Though quite why emacs is using it's own byte compiled elisp implementation to ungzip the .el.gz files rather than libz is a bit of a design error, IMO]
> Personally I would advocate disabling the gzipping of the source .el files ...
It appears that not compressing a code which is supposed to provide decompression would be enough to avoid those problems. Some other .el files are not compressed for whatever reasons.
You will not bump into that unless you need/want to deal with elisp sources.
> Though quite why emacs is using it's own byte compiled elisp implementation to
> ungzip the .el.gz files
emacs is actually using 'gzip -c -q -d', or some other program depending on a compression type, to do such job. elisp code handles choices and interfaces with emacs (loading files or libraries, inserting into buffers, etc...). Byte-compiled files are unaffected here because they are not compressed.
note it's emacs's Makefile in "make install", not one of our .spec scripts who does this *.el compression
I simply called "gunzip" to those two files in the .spec and this seems to be enough, the file list scripts after that are clever enough to include the files in the package
as this will not touch many users, I will fix this in rawhide only:
fixed in emacs-23.1-12.fc13
> I simply called "gunzip" to those two files in the .spec and this seems to be
Yes, sure; as long as that spec file is not particular to *.gz pattern. Uncompressing those two was exactly how I was "fixing" that when needed. Thanks!
emacs-23.1-19.fc12 has been submitted as an update for Fedora 12.
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.
emacs-23.1-13.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.