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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
