Bug 1234563

Summary: Package should not ship a separate emacs sub-package
Product: [Fedora] Fedora Reporter: Jonathan Underwood <jonathan.underwood>
Component: libidnAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: harald, kevin, mlichvar, puntogil
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: libidn-1.30-4.fc23 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-25 12:36:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1234479    

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.