Emacs packaging guidelines

Vít Ondruch vondruch at redhat.com
Thu Jul 30 10:48:46 UTC 2015


Dne 30.7.2015 v 12:39 Jonathan Underwood napsal(a):
> 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.
>

These are definitely fair points, but at the end, this should be left up
to the maintainer if there will be -emacs package and the general
preference should be to support the subpackages. I hope it will give as
greater opportunities with incoming boolean dependencies, such as
"install the -emacs subpackage when emacs is already installed".


Vít



More information about the devel mailing list