Jonathan Underwood <jonathan.underwood(a)gmail.com> writes:
On 4 January 2016 at 14:35, Jan Synacek <jsynacek(a)redhat.com>
wrote:
> ...
> Any comments? Maybe there are still people that were involved with the
> change?
Those unaware of history are doomed to repeat it :)
That's why I'm asking ;)
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.
This is the explanation I was looking for, thank you!
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
Cheers,
--
Jan Synacek
Software Engineer, Red Hat