Ok, emacs-libidn is now merged with the main package. This means emacs-filesystem will be installed on all systems and could possibly be merged with the filesystem package.

This means, as systemd requires libidn, emacs-filesystem is part of _every_ minimal installation, which means, that one has to build emacs just to satisfy the dependency for a minimal system.

I don't see the issue with having emacs-filesystem installed on minimal systems, as it takes no space at all.

I do see why you might not want to to have to build emacs when bootstrapping a new arch, just to create the emacs-filesystem package. Is that the main concern?

Funnily enough, my F22 system (far from minimal) didn't even have libidn installed. when did systemd grow such a dependency - that's probably a better place to tackle this.

> I don't see the issue with having emacs-filesystem installed on minimal systems, as it takes no space at all.

It is still pollution (of the rpmdb), and the actual Emacs extension does take up non-zero space.

This also results in the emacs SRPM being part of the critical path (because of emacs-filesystem), see the thread on the devel mailing list.

I don't understand why Emacs extensions should not be in a separate subpackage. It is by far the cleanest way. Not all the world uses Emacs!

The Emacs addons packaging guideline used to require that all addons were in a sub-package. The result was a lots of packagers would punt the problem, and stick the Emacs files into the docs. The current guidelines attempt to make it simpler for packagers to do the right thing.

The guidelines use SHOULD, so where there's good reasons to not follow them, so when splitting out into a sub-package is sensible, then packagers can.

Polluting the main package with Emacs-specific crap is NOT "the right thing". The guidelines now explicitly forbid (or at least discourage) doing the right thing, just to accomodate for packager laziness.

I suggest you redraft the Emacs packaging guidelines and take the proposal to the FPC, then.