Bug 484830 - emacs-el files compressed a bit to far
emacs-el files compressed a bit to far
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Novotny
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-10 01:25 EST by Michal Jaegermann
Modified: 2010-04-20 09:09 EDT (History)
3 users (show)

See Also:
Fixed In Version: emacs-23.1-13.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-14 08:39:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2009-02-10 01:25:37 EST
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:

Recursive load/usr/share/emacs/22.3/lisp/jka-compr.el.gz/usr/share/emacs/22.3/lisp/jka-compr.el.gz/usr/share/emacs/22.3/lisp/jka-compr.el.gz/usr/share/emacs/22.3/lisp/jka-compr.el.gz/usr/share/emacs/22.3/lisp/jka-compr.el.gz/usr/share/emacs/22.3/lisp/term/x-win.el.gz

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):
emacs-22.3-3.fc10

How reproducible:
always

Additional info:
Possible that jka-cmpr-hook.el.gz can be left alone but I did not risk it.
Comment 1 Daniel Novotny 2009-10-13 09:35:27 EDT
(In reply to comment #0)
> Description of problem:
> 
> With emacs-el files installed but corresponding .elc files "hidden"
how do you hide them?
Comment 2 Michal Jaegermann 2009-10-13 13:58:28 EDT
> 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.
Comment 3 Jonathan Underwood 2009-10-13 14:06:18 EDT
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]
Comment 4 Michal Jaegermann 2009-10-13 15:30:49 EDT
> 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.
Comment 5 Daniel Novotny 2009-10-14 08:39:17 EDT
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
Comment 6 Michal Jaegermann 2009-10-14 13:42:24 EDT
> 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!
Comment 7 Fedora Update System 2010-03-24 20:59:09 EDT
emacs-23.1-19.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/emacs-23.1-19.fc12
Comment 8 Fedora Update System 2010-03-30 19:17:51 EDT
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11
Comment 9 Fedora Update System 2010-04-01 12:09:45 EDT
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11
Comment 10 Fedora Update System 2010-04-20 09:08:23 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.