Remove dnf and yum from protected packages #1926
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 2, 2023
evan-goode
force-pushed
the
evan-goode/unprotect-dnf
branch
from
abb0843 to
0b4f484
Compare
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Jul 17, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Jul 17, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Aug 28, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Aug 28, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Sep 12, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
evan-goode
added a commit
to rpm-software-management/libdnf
that referenced
this pull request
Sep 19, 2023
As described at the end of this comment: rpm-software-management/dnf#1926 (comment) There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. Obsoleting a protected package is less likely to happen accidentally than removing it. But this change does mean that a protected package could be obsoleted, and then the obsoleter could be removed, which is perhaps not ideal. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed. IMO a better, more "declarative" way, might be to disallow any transaction that would result in a protected package no longer being provided. But I'm not sure how to do this without modifying libsolv.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For the DNF => DNF5 upgrade path in Fedora 39.
See also rpm-software-management/libdnf#1599.
This change should ideally be merged soon and released in Fedora 37. Versions of DNF 4 older than this change will not be able to replace
dnfwithdnf5when upgrading Fedora 37 to Fedora 39. The Fedora documentation strongly urges users to fully update their system before attempting an upgrade to a new Fedora release, but there will surely be a small set of users who disregard the documentation and attempt an upgrade from an old version of DNF4 on Fedora 37 straight to Fedora 39. In my opinion, we should therefore remove the protection soon to minimize the size of this group of users. But this concern should be weighed against the risks of leaving thednfpackage unprotected. It could instead be argued that we should wait to merge this change until closer to the Fedora 39 release date.An alternative approach would be to change the behavior of
libdnfsuch that the replacement of a package due to anObsoleteswould not be considered a removal of a protected package. Currently, it seems thatdnfcannot upgrade itself todnf5sincednfandyumare protected, even ifdnf5provides and obsoletesdnfandyum. But it may not be worth the effort to make this change inlibdnfwhen it is being replaced by DNF5 soon.