Latest revision as of 09:14, 10 July 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

Name: Benson Muite
Email: benson_muite@emailplus.org

Current status

Targeted release: Fedora Linux 40
Last updated: 2023-07-10
[<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

-

Sorry, but that is just plain wrong, IMO. For example, we have used the deprecation process for the sonatype Java packages. They built just fine, and there were no security issues. Instead, they were made unnecessary and obsolete by changes in the Java ecosystem. If they were orphaned, they'd get retired after some delay, but this is not what was wanted. We want to keep them around as long as something depends on them, but disallow any such new dependencies to be added. Both orphaning and retirement have completely different semantics. Deprecation is for the case where the maintainers know that the package should be removed, orphaning is for the case where the package is or may still be useful but maintainers don't have enough time, and retirement is for the case where the package is not useful or broken and can be get rid of immediately. https://pagure.io/fesco/fesco-docs/pull-request/75

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

This should allow for smoother upgrades by enabling improvement of packages that are dependencies as the community will have an opportunity to improve them should they choose to do so.

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

@@ Line 59: / Line 59: @@
 == Feedback ==
 <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
+-
+* Sorry, but that is just plain wrong, IMO. For example, we have used the deprecation process for the sonatype Java packages. They built just fine, and there were no security issues. Instead, they were made unnecessary and obsolete by changes in the Java ecosystem. If they were orphaned, they'd get retired after some delay, but this is not what was wanted. We want to keep them around as long as something depends on them, but disallow any such new dependencies to be added. Both orphaning and retirement have completely different semantics. Deprecation is for the case where the maintainers know that the package should be removed, orphaning is for the case where the package is or may still be useful but maintainers don't have enough time, and retirement is for the case where the package is not useful or broken and can be get rid of immediately. https://pagure.io/fesco/fesco-docs/pull-request/75
 == Benefit to Fedora ==
@@ Line 89: / Line 92: @@
 -->
- 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 ==
 * 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?-->
 * 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?-->
 * 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.
 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 -->
@@ Line 117: / Line 112: @@
 <!-- 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 -->
-No current community initiatives.
 == Upgrade/compatibility impact ==
@@ Line 126: / Line 119: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+This should allow for smoother upgrades by enabling improvement of packages that are dependencies as the community will
+have an opportunity to improve them should they choose to do so.
 == How To Test ==

Search

Changes/DeprecationPolicy: Difference between revisions