Emacs packaging guidelines

[Vít Ondruch]

Dne 30.7.2015 v 12:27 Michael Schwendt napsal(a):
> 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".

I read that, but there is no really explained why it should not be
subpackage. Moreover, I am not sure if you support my point or you are
against :)

Vít

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