Emacs packaging guidelines

[Michael Schwendt]

On Thu, 30 Jul 2015 10:18:13 +0200, Vít Ondruch wrote:

> Actually what is the point of following?
> 
> ```
> Case II
> 
> Where a package's principal functionality does not require (X)Emacs, but
> the package also includes some auxiliary Elisp files to provide support
> for the package in (X)Emacs, these should be included in the main
> package which will need to Require the emacs-filesystem and/or
> xemacs-filesystem packages. More detail below.
> ```
> 
> Why the files should be provided in the main package? Why it should not
> be subpackage?

There's some background at the bottom of the page:

  https://fedoraproject.org/wiki/Packaging:Emacs#Other_packages_containing_Emacsen_add-ons_.28Case_II.29

  | It is often the case that a software package, while not being
  | primarily an Emacs add-on package, will contain components for
  | (X)Emacs. For example, the Gnuplot program contains some elisp files
  | for editing Gnuplot input files in GNU Emacs and running Gnuplot
  | from GNU Emacs. In this case, we want to enable the (X)Emacs support
  | IF (X)Emacs is installed, but we don't want to mandate the
  | installation of (X)Emacs on installation of this package since
  | (X)Emacs is not required for providing the core functionality of the
  | package. To enable this, the emacs-filesystem and xemacs-filesystem
  | sub-packages were created which own the /usr/share/emacs/site-lisp
  | and /usr/share/xmeacs/site-packages directories respectively. A
  | package can then Require these (x)emacsfilesystem packages in order
  | to install their Elisp files without pulling in (X)Emacs and their
  | dependency chain.

It's like saying "we don't care much about those files, we just don't
want to delete them, so we include them to make them available somewhere
for those people who manage to find them, and btw, Emacs/XEmacs users
may want to look at using Emacs' own package management anyway since
it won't be possible to package all available extensions".

Reminds me of:

  $ dnf list texlive\*|wc -l
  5262

> It is exaclty against principles applied anywhere else,
> e.g. if I have library with binding for some language, these binding
> will be probably in corresponding -language subpackage.

True. It seems to be an arbitrary decision to not follow the general
%{parent}-%{child} naming guidelines for add-on packages. It's hiding add-ons
within the base package, which obviously cannot follow the naming guidelines,
if it's not only an add-on to X/Emacs. Still that's hiding the add-ons from
the emacs-foo namespace unless the "Provides" is kept forever.