Bug 49022 - Changes in the (X)Emacs-modules packaging strategy
Summary: Changes in the (X)Emacs-modules packaging strategy
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: xemacs   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Aaron Brown
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-13 01:48 UTC by Enrico Scholz
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-13 14:13:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Enrico Scholz 2001-07-13 01:48:04 UTC
[This report is not related to XEmacs directly but to a lot of other
 packages containing elisp-modules]

Let me begin with the problem:

- There are existing two different flavors of the Emacs editor which
  can run the same modules. Nevertheless the produced byte-code is not
  compatible so it can not be shared between them.

- Currently (x)emacs is supported by RH only sparely; a lot of packages
  are providing emacs modules in their source tar-balls, but they are
  not available in the binaries -- especially not for XEmacs (which
  rulez ;) ).

In the following considerations it is to differ between:
1. byte-code (*.elc)
2. source-code (*.el)
3. data
4. system-depending executables
5. code being executed at system^WEmacs start (currently located in
   sitestart.d directories)

I am assuming that:

- modules shall be available for both XEmacs and GNU Emacs; especially
  for XEmacs because it rulez
- byte-code(1) can not be shared
- source-code(2), data(3) + executables(4) can be shared
- there should be shared as much as possible
- site-start-files(5) should not be compiled but marked as %config-files
- it is not a solution to put modules into the emacs and xemacs RPMS. There
  are too much modules to catch them all, the (x)emacs packages will be
  difficulty to maintain and because the shipped (x)emacs-packages are very
  conservative, people like I who are using gamma versions will missing
  all these modules.

My experiences have shown that the init-stuff(5) can be shared also; but
because XEmacs is more powerful in handling `autoload' functions (you
know: XEmacs rulez) there must be taken special care. I will explain it

My suggestion for the future Red Hat (X)Emacs package strategy is:

- binaries(1) are installed under
  * /usr/lib/xemacs/xemacs-packages/lisp/<packagename> for XEmacs. I don't
    know if .../xemacs-packages/... is the best choice. XEmacs knows a
    `site-packages' directory which seems to be more applicably. To keep
    backward compatibility `xemacs-packages' was chosen.
  * /usr/share/emacs/site-lisp/<packagename> for GNU Emacs; if there
    are only one or two files they can be installed directly in the
    site-lisp directory. Because of the autoload-mechanism of XEmacs
    that is not applicably there.

- a new directory `/usr/share/emacs-common' must be added where
  * sources(2) get installed in `lisp/<packagename>'; there will be
    added symlinks to them in the binary-directories mentioned above
  * data(3) get installed in etc/ or somewhere else;
    `/usr/lib/xemacs/xemacs-packages/etc' and `/usr/share/emacs/etc'
    will be symlinks to this etc/ directory
  * a directory `sitestart.d' exists and contains site-start files(5)

- executables(4) get installed somewhere else

- `/usr/lib/xemacs/xemacs-packages/lisp/sitestart.d' and
  `/usr/share/emacs/lisp/sitestart.d' will be symlinks to
  `/usr/share/emacs-common/sitestart.d'. There the init-files(5) will be

The realization in .spec-files:

  I have submitted some RPMS containing elisp-modules to rhcontrib.bero.org
  (most recent one is MagicPoint-el following the most of my suggestions).

  The .spec files are ugly -- especially because of the 50 lines of macros
  at the beginning. But these macros (paths, compilation commands) can be
  shared between all packages providing elisp-modules. Therefore there
  should be added some support to RPM...

  The real building and installation happens twice -- for each emacs one
  time. The installation is nearly the same for both; perhaps there
  exists some RPM-magic which allows it to embed it into a single macro.

  To allow building of the RPM if one of Emacs or XEmacs is not installed
  I test for their existence and build only possible subpackages. In
  official RH packages this part can be omitted probably...

  Altogether it should be possible to keep the spec-files clean and


  The XEmacs autoload mechanism:
    XEmacs has an own packaging-concept allowing the automatic
    generation of

|               (autoload 'feature "place" "doc" ...)

    statements being executed at system-start. To enable it there must
    be added only a ";;;###autoload" comment before the <feature> and
    XEmacs be called with

|     xemacs -vanilla -batch -l autoload -f batch-update-directory .

    A similar mechanism is existing for customizations. For details see
    etc/BETA -> "Manual procedures for package management"

    Finally there are two new files generated: `auto-autoloads.el' and
    `custom-load.el'. To avoid conflicts with other packages, each
    package must have its own directory.

    An advantage of this mechanism is that auto-load stuff of <feature>
    (documentation, interactive-flag) is kept in sync with the code. The
    old method can lead to dangling or incorrect autoloads.

    To prevent the interfering of manual and automatic autoloading in
    the init-files I suggest something like:

|         (unless (featurep 'MagicPoint-autoloads)
|            (autoload 'mgp-mode "mgp-mode" "Major..." t nil))
    The `MagicPoint-autoloads' feature will be defined by the XEmacs
    autoload mechanism.

  RPM does not support emacs-macros currently:
    Either they will be added explicitly by the rpm-maintainer or
    an autoload-mechanism will be added to RPM. Latter means that
    packages can place files under /etc/rpm which will be loaded by
    rpm automatically. Currently they must be entered into the
    `macrofiles' variable manually.

Comment 1 Trond Eivind Glomsrxd 2001-07-13 02:44:57 UTC
Your assumptions are wrong - 

* XEmacs is not the primary supported emacs editor in Red Hat Linux, it's
shipped as is for those who want to sacrifice stability, bugs and speed to get a
better looking emacs. When Emacs 21 is out, the question on whether to drop
XEmacs or not is open. As it is not a core supported package, a feature not
being available for it is not a problem - it's desirable for it to be, though

* site-packages are for site-packages, ie. things added by the sysadmin. Not us.

Adding a complicated scheme rather than supporting just emacs in a package is
not desirable. The problem will probably go away soon.

Comment 2 Enrico Scholz 2001-07-13 14:13:03 UTC
Hmm, who brought you on the idea that GNU Emacs is more stable and faster than
XEmacs? (I agree with you that it looks better than GNU Emacs and as you can
guess probably, I am voting against dropping XEmacs).

Adding support for XEmacs does not need large effort in most cases -- only an
extra compilation + installation is needed. With rpm-4.0.3 you can use
parameterized macros so it can be written

%{__emacs_compile  *.el}
%{__xemacs_compile *.el}

%{__emacs_install  -i init-script.el}
%{__xemacs_install -i init-script.el}
where the %{...} macros are macros which can be shared between all .spec-files.
This looks like a simple scheme...

Currently (rpm-4.0.2) it is more complicated because parameterized macros are
broken there.

Are not rpms providing extra modules `site-packages' installed by the local
admin? E.g. you are placing GNU Emacs modules into a `site-lisp' directory also.

I am interpreting the XEmacs directory scheme in that way that `xemacs-packages'
and `mule-packages' are reserved for official xemacs-packages.

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