From Fedora Project Wiki
No edit summary
Line 89: Line 89:
-->
-->


The main benefit is a clear rationale for deprecating packages.  There is a rationale for
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
[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
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 is a proposed Change for Fedora Linux.
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


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


  • 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


  • 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.

Release Notes