Bug 1234563 - Package should not ship a separate emacs sub-package
Summary: Package should not ship a separate emacs sub-package
Alias: None
Product: Fedora
Classification: Fedora
Component: libidn
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: EmacsPackagingViolations
TreeView+ depends on / blocked
Reported: 2015-06-22 17:53 UTC by Jonathan Underwood
Modified: 2016-10-25 11:28 UTC (History)
4 users (show)

Fixed In Version: libidn-1.30-4.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-25 12:36:39 UTC

Attachments (Terms of Use)

Description Jonathan Underwood 2015-06-22 17:53:27 UTC
The Emacs add-on packaging guidelines no longer stipulate that packages which also bundle support for Emacs should split out those Emacs files into separate sub-packages. This package should instead ship those files with the main package which should also Require emacs-filesystem. See https://fedoraproject.org/wiki/Packaging:Emacs for more detail.

Comment 1 Miroslav Lichvar 2015-06-25 12:36:39 UTC
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.

Comment 2 Harald Hoyer 2015-07-29 16:52:59 UTC
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.

Comment 3 Jonathan Underwood 2015-07-29 18:47:46 UTC
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?

Comment 4 Jonathan Underwood 2015-07-29 18:51:13 UTC
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.

Comment 5 Kevin Kofler 2016-10-25 01:40:25 UTC
> 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!

Comment 6 Jonathan Underwood 2016-10-25 07:12:42 UTC
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.

Comment 7 Kevin Kofler 2016-10-25 11:22:09 UTC
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.

Comment 8 Jonathan Underwood 2016-10-25 11:28:53 UTC
I suggest you redraft the Emacs packaging guidelines and take the proposal to the FPC, then.

Note You need to log in before you can comment on or make changes to this bug.