< Changes
(→Scope) |
|||
| Line 96: | Line 96: | ||
* Proposal owners: | * Proposal owners: | ||
** The feature is ready in Pull Request - https://github.com/rpm-software-management/libdnf/pull/1279 | ** The feature is ready in Pull Request - https://github.com/rpm-software-management/libdnf/pull/1279 | ||
** PRs only wait for release of libsolv | ** PRs only wait for a release of libsolv | ||
** The Feature will be enabled in upstream, therefore from Fedora 36 we start to | ** The Feature will be enabled in upstream as default, therefore from Fedora 36 we start to release libdnf without a revert patch of default in comparison to upstream. | ||
<!-- 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: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
The change requires a new release of libsolv. | |||
<!-- 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: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
No coordination required. | |||
<!-- 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: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
No update required. | |||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. --> | ||
Revision as of 08:54, 16 September 2021
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.
For details on how to fill out this form, see the documentation.
Enable exclude_from_weak_autodetect by default in LIBDNF
Summary
exclude_from_weak_autodetect enables autodetection of unmet weak dependencies (recommends or supplements) of installed packages and block installation of packages satisfying unmet dependencies.
Owner
- Name: Jaroslav Mracek
- Email: jmracek@redhat.com
Current status
- Targeted release: Fedora 36
- Last updated: 2021-09-16
- 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
The feature is designed to prevent an install of removed weak dependencies from the system by users and to not install weak dependencies missing after system deployment. It will change the behaviour of DNF, microdnf, and PackageKit. The feature will be backported to all Fedoras, but in default the feature will be off. Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
The default value for exclude_from_weak_autodetect configuration can be overridden in /etc/dnf/dnf.conf
Feedback
The feature was requested by Miro Hroncok mhroncok@redhat.com. Additional feedback: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
Benefit to Fedora
After installation of a fresh system the first upgrade will not install a lot of weak dependencies. Some of them were excluded from kick-start installation set for a good reasons (security, image size, minimal functional set, ...), but after the first update, all weak dependencies are installed, therefore some feature of deployment simply disappear.
Scope
- Proposal owners:
- The feature is ready in Pull Request - https://github.com/rpm-software-management/libdnf/pull/1279
- PRs only wait for a release of libsolv
- The Feature will be enabled in upstream as default, therefore from Fedora 36 we start to release libdnf without a revert patch of default in comparison to upstream.
- Other developers:
The change requires a new release of libsolv.
- Release engineering: #Releng issue number
No coordination required.
- Policies and guidelines: N/A (not needed for this Change)
No update required.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
Upgrade/compatibility impact
No manual changes will be required. After libdnf update the feature will be on by default.
How To Test
1. Install package without satisfied weak dependencies 2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it will not install weak dependencies of already installed packages. With exclude_from_weak_autodetect=false, weak dependencies will be installed on upgrade.
User Experience
The change in default will help to keep some values for particular deployments (minimal system will be still minimal without disabling weak dependencies). Users will be able to remove particular weak dependencies and they will be not installed on the first upgrade. In case when feature will not work according to user expectation it can be switched off in dnf configuration file.
Dependencies
libsolv - Required code changes are already in upstream. We only wait for the next release of libsolv.
Contingency Plan
There are no external dependencies, therefore we can easily to postpone the feature and the change of default behaviour.
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
The feature will be documented in dnf man pages.
N/A (not a System Wide Change)