No edit summary |
|||
| Line 89: | Line 89: | ||
--> | --> | ||
The main benefit is a clear rationale for deprecating packages. There is a rationale for [https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#_orphaning_and_retiring_packages Orphaning and Retiring packages] but none for deprecation. Having a broad set of natively packaged software makes a distribution more useful. Deprecating packages that could still be useful weakens the ecosystem. One could examine status of upstream projects to make suggestions if a packager should become an upstream maintainer and if maintainers of packages that depend on a package should consider removing that package as | |||
a dependency. However, forcing new packages not to depend on a particular package without valid cause will weaken the ecosystem since it maybe the case that an existing package can be improved. | |||
makes a distribution more useful. Deprecating packages that could still be useful weakens the ecosystem. | |||
One could examine status of upstream projects to make suggestions if a packager should become an upstream | |||
maintainer and if maintainers of packages that depend on a package should consider removing that package as | |||
a dependency. However, forcing new packages not to depend on a particular package without valid cause | |||
will weaken the ecosystem since it maybe the case that an existing package can be improved. | |||
== Scope == | == Scope == | ||
Revision as of 08:10, 30 June 2023
Requirements for Package Deprecation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
Detail requirements for package deprecation as unmaintained and fails to build or a security concern.
Owner
- Name: Benson Muite
- Email: benson_muite@emailplus.org
Current status
- Targeted release: Fedora Linux 40
- Last updated: 2023-06-30
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Package deprecation prevents addition of new packages to Fedora that depend on the deprecated package. This is reasonable when a package is a security concern or no longer works in Fedora. To encourage a broad software ecosystem, package deprecation should only be done in exceptional cases and otherwise packages should just be orphaned and retired to allow other maintainers to take over.
Feedback
Benefit to Fedora
The main benefit is a clear rationale for deprecating packages. There is a rationale for Orphaning and Retiring packages but none for deprecation. Having a broad set of natively packaged software makes a distribution more useful. Deprecating packages that could still be useful weakens the ecosystem. One could examine status of upstream projects to make suggestions if a packager should become an upstream maintainer and if maintainers of packages that depend on a package should consider removing that package as a dependency. However, forcing new packages not to depend on a particular package without valid cause will weaken the ecosystem since it maybe the case that an existing package can be improved.
Scope
- Proposal owners: Add this policy to the FESCO policy documents.
- Other developers: No work needed from other developers other than giving a clear rationale when proposing to deprecate a package.
- Release engineering: No changes needed
- Policies and guidelines: Change required draft pull request
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives:
No current community initiatives.
Upgrade/compatibility impact
How To Test
No tests needed.
User Experience
Users will have a wider selection of natively compiled packages that are well integrated with Fedora.
Dependencies
This change does not target a specific package directly, though it will allow for a broader set of dependencies.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) This is a policy change, no contingency mechanism is needed.
- Contingency deadline: This is a policy change, can be implemented if there is agreement.
- Blocks release? No
Documentation
Pull request with suggested change.