Bug 13771 - Proposal for an improved processing of .el & .elc files
Summary: Proposal for an improved processing of .el & .elc files
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 3
Hardware: i586 Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-20 08:51 CEST by Gilles Allard
Modified: 2014-07-20 15:11 CEST (History)
0 users

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Path to "autoconf" spec file to improve .el files processing (example) (2.48 KB, patch)
2014-07-20 08:53 CEST, Gilles Allard
Details | Diff

Description Gilles Allard 2014-07-20 08:51:21 CEST
Description of problem:
Many packages provide .el & .elc files but, very often, their installation path is hard coded in spec file and they are installed for emacs. The consequence is that, if the end user installed xemacs, these .el & .elc files are not taken into account because xemacs & emacs default load paths are different (resp. xemacs/site-lisp & emacs/site-lisp under /usr/share). But neither the build not the installation fail.

The best example is the spec file from "autoconf-2.69-2.mga3.src.rpm" : configure try to guess what (Emacs or Xemacs) is installed on the build machine and setup the installation target directory to emacs/site-lisp or xemacs/site-lisp depending on what was found.
During the packaging step and in the list of the files in sub-package, the installation path of the .el & .elc files is hard coded to "emacs/site-lisp".
If emacs is installed on the build machine, every thing runs fine. But if xemacs is found, packaging step fails because "/usr/share/emacs/site-lisp/*.el" files don't exists. This is due to the mismatch between what configure found and what the spec file assumes.
On the end user's point of view the (possible) mismatch between what was packaged and what exists on his machine remains.

This proposal consists of the following points :

- during the build & packaging process, spec file tries to guess what is installed (Emacs or Xemacs) and setup installation paths of .el files according to what was found. These files are packaged according to that. This fixes any possible mismatch with what configure found.

- during installation by the end user, the "%post" scriptlet tries in turn to guess what is installed (it may be different from the build machine) and, if found different, relocates all the .el & .elc files to the right directory. Of course the "%postun" scriptlet does the same sort of work when removing the package.

As an example, the attached file provides a patch to the spec file from "autoconf-2.69-2.mga3.src.rpm"

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Gilles Allard 2014-07-20 08:53:37 CEST
Created attachment 5300 [details]
Path to "autoconf" spec file to improve .el files processing (example)
Comment 2 David Walser 2014-07-20 15:11:09 CEST
It makes no sense to add this kind of complication to every spec that ships .el files.  Maybe xemacs should just be patched to look in the locations emacs uses.

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX


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