Bug 484830

(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):

mkdir /var/tmp/hide
cd /usr/share/emacs/23.1/lisp
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:

$ emacs 
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:

uncompressing encoded-kb.el.gz...
uncompressing encoded-kb.el.gz...done

and starts.

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
> enough

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.
http://admin.fedoraproject.org/updates/emacs-23.1-19.fc12

emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11

emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11

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.