From Fedora Project Wiki
Line 95: Line 95:
* Proposal owners: Add this policy to the [https://docs.fedoraproject.org/en-US/fesco/ FESCO policy documents].
* Proposal owners: Add this policy to the [https://docs.fedoraproject.org/en-US/fesco/ FESCO policy documents].
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: No work needed from other developers other than giving a clear rationale when proposing to deprecate a package. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: No work needed from other developers other than giving a clear rationale when proposing to deprecate a package. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: No changes needed <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: No changes needed <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


* Policies and guidelines: Change required [https://pagure.io/fesco/fesco-docs/pull-request/75 draft pull request] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: Change required [https://pagure.io/fesco/fesco-docs/pull-request/75 draft pull request] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 112: Line 109:
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


* Alignment with Community Initiatives:  
* Alignment with Community Initiatives: No current community initiatives.
<!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider -->
<!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider -->
No current community initiatives.


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==

Revision as of 08:12, 30 June 2023


Requirements for Package Deprecation

Important.png
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