Emacs packaging guidelines

[Jonathan Underwood]

On 30 July 2015 at 11:27, Michael Schwendt <mschwendt at gmail.com> wrote:
> 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".

Yes, that's part of the story. The current guidelines were put in
place at Fedora 16. Prior to that, the guidelines stipulated that the
emacs bits were split off into an emacs-foo sub-package, as Vit
suggests (and I would agree) is more compliant with other packaging
practices. However, many packagers ignored that and just included the
emacs files in the main package without any kind of emacs dependency,
no byte compilation etc, and most reviewers didn't pick up on this
during package review. It was also argued that splitting out one or
two files into a sub-package bloated the package set and associated
metadata. So, the current guideline was an attempt to be a bit more
pragmatic about the situation, and have the nice effect that a user
who installs emacs automagically has all these bits working without
having to manually do a bunch of dnf install emacs-blah packages. So,
that's how we got to here. If there's a general consensus that we want
to switch back to the splitting out of emacs sub-packages, I would
definitely support that initiative. But I think (and I'm not speaking
for them) the FPC would want to see good reasons for flip-flopping the
guidelines again.




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

That's right. Happens also for vim scripts etc as well.

Jonathan.