Bug 1234563
| Summary: | Package should not ship a separate emacs sub-package | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | libidn | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | harald, kevin, mlichvar, puntogil |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1234479 | ||
|
Description
Jonathan Underwood
2015-06-22 17:53:27 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. 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. |