On 4 January 2016 at 14:35, Jan Synacek <jsynacek@xxxxxxxxxx> wrote: > Hello, > > long time ago, there was a request to create the emacs-filesystem > package [1], so other packages could drop their emacs-specific files > there. I believe it was done the other way around... Those files are > useless without emacs to begin with. I think packages that have emacs > snippets / modes should have a "-emacs" subpackage (or something like > that) that depends on emacs itself. > > The following packages now depend on emacs-filesystem (I have omitted > i686 variants for brevity): > > a2ps-0:4.14-28.fc23.x86_64 > anthy-0:9100h-28.fc23.x86_64 > asymptote-0:2.35-3.fc23.x86_64 > autoconf-0:2.69-21.fc23.noarch > bigloo-0:4.1a-9.2.fc23.x86_64 > clisp-0:2.49-18.20130208hg.fc23.x86_64 > cmake-0:3.3.2-1.fc23.x86_64 > crm114-0:0-10.20100106.fc23.x86_64 > cscope-0:15.8-12.fc23.x86_64 > desktop-file-utils-0:0.22-5.fc23.x86_64 > emacs-common-1:24.5-6.fc23.x86_64 > emacs-pysmell-0:0.7.3-4.fc23.noarch This one (pysmell) is a packaging bug - pure emacs add on packages have no need to install emacs-filesystem (since they require emacs proper). > ftnchek-0:3.3.1-21.fc23.x86_64 > gambit-c-0:4.7.9-1.fc23.x86_64 > git-0:2.5.0-4.fc23.x86_64 > global-0:6.5.1-1.fc23.x86_64 > jflex-0:1.6.1-2.fc23.noarch > libidn-0:1.32-1.fc23.x86_64 > librep-0:0.92.5-1.fc23.x86_64 > mercurial-0:3.5.1-1.fc23.x86_64 > mozc-0:2.17.2077.102-5.fc23.x86_64 > ninja-build-0:1.6.0-1.fc23.x86_64 > nodejs-tern-0:0.7.0-6.fc23.noarch > perl-SystemPerl-0:1.344-2.fc23.x86_64 > pypy-libs-0:4.0.0-3.fc23.x86_64 > pypy3-libs-0:2.4.0-2.fc23.x86_64 > ratpoison-0:1.4.8-2.fc23.x86_64 > reposurgeon-0:3.29-1.fc23.noarch > root-0:5.34.32-5.fc23.x86_64 > rpmdevtools-0:8.6-2.fc23.noarch > tpp-0:1.3.1-19.fc23.noarch > uim-0:1.8.6-8.fc23.x86_64 > why-0:2.35-9.fc23.x86_64 > yast2-devtools-0:3.1.36-2.fc23.noarch > > I think it would be better that these packages had their emacs > subpackages, instead of the other way around. Not only would that make > more sense, but itw would also resolve the WTF moments when installing > unrelated packages that suddenly require emacs-filesystem to be > installed as a dependency. > > Any comments? Maybe there are still people that were involved with the > change? Those unaware of history are doomed to repeat it :) It previously was the case that packages that also shipped support files for emacs were required to ship the emacs bits in a sub-package. However, the result was that very few packagers actually complied, and indeed some just shipped the emacs bits as %docs. The move to using emacs-filesystem (proposed by me) was a move to be consistent with vim and xemacs practices. The packages you are talking about are primarily not emacs add-ons, but packages that also ship a couple of elisp files to provide auxillary emacs support if emacs is present on the system. Pulling in the whole emacs stack in such cases would be overkill. However, having the user have to install endless emacs-foo packages just to install a few elisp files also seemed like overkill. The emacs-filesystem approach was a happy compromise, and already a widely used strategy in Fedora (see vim, xemacs etc). I still think it's the best approach, personally, as splitting out all these little elisp files into their own packages just increases package metadata bloat. Any change to the current situation would need to be agreed with the FPC, and coordinated distro wide. Given that we're only now approaching compliance with the current emacs add-on packaging guidelines, I can imagine some resistance to the change you're proposing. I don't see why there are "WTF moments" when emacs-filesystem i installed - it contains a few directories, and nothing else. For info: https://fedoraproject.org/wiki/Packaging:Emacs -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
