Dne 30.7.2015 v 12:39 Jonathan Underwood napsal(a): > On 30 July 2015 at 11:27, Michael Schwendt <mschwendt@xxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
