-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow obsoletion of protected packages #1610
Merged
evan-goode
merged 1 commit into
rpm-software-management:dnf-4-master
from
evan-goode:evan-goode/f39
Sep 19, 2023
Merged
Allow obsoletion of protected packages #1610
evan-goode
merged 1 commit into
rpm-software-management:dnf-4-master
from
evan-goode:evan-goode/f39
Sep 19, 2023
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
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Jul 17, 2023
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Jul 20, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5.
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Jul 26, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5.
Closing, see explanation in rpm-software-management/dnf5#733. |
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Aug 28, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5.
8f8d3ee
to
8c005d2
Compare
Reopening, see rpm-software-management/dnf5#733. |
8c005d2
to
296aa8f
Compare
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Aug 28, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed.
evan-goode
added a commit
to evan-goode/dnf5
that referenced
this pull request
Sep 12, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed.
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.
296aa8f
to
045ae61
Compare
github-merge-queue bot
pushed a commit
to rpm-software-management/dnf5
that referenced
this pull request
Sep 13, 2023
This is the libdnf5 companion to rpm-software-management/libdnf#1610; if we change DNF 4, then we should also change DNF 5. There should be some mechanism for replacing even protected packages, e.g. to upgrade DNF to DNF 5. We unprotected dnf to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection of dnf and python3-dnf in DNF 4 and adding a protection of dnf5 in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsolete dnf with dnf5. The running kernel is treated as a special case; obsoletes of the running kernel are still not allowed.
j-mracek
approved these changes
Sep 19, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
10958ca
into
rpm-software-management:dnf-4-master
3 checks passed
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Sep 20, 2023
Now that obsoletion of protected packages is allowed (rpm-software-management#1610), it's best to hardcode the protection of dnf here instead of using the file in /etc/dnf/protected.d. This way, DNF 4 cannot uninstall itself, but DNF 5 can uninstall DNF 4, and likewise (given a similar change in DNF 5), DNF 5 cannot uninstall itself, but DNF 4 can uninstall DNF 5. Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221905 Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221907
evan-goode
added a commit
to evan-goode/libdnf
that referenced
this pull request
Sep 21, 2023
Now that obsoletion of protected packages is allowed (rpm-software-management#1610), it's best to hardcode the protection of dnf here instead of using the file in /etc/dnf/protected.d. This way, DNF 4 cannot uninstall itself, but DNF 5 can uninstall DNF 4, and likewise (given a similar change in DNF 5), DNF 5 cannot uninstall itself, but DNF 4 can uninstall DNF 5. Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221905 Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221907 = changelog = msg: Allow dnf to be removed by DNF 5 type: enhancement
inknos
pushed a commit
that referenced
this pull request
Sep 25, 2023
Now that obsoletion of protected packages is allowed (#1610), it's best to hardcode the protection of dnf here instead of using the file in /etc/dnf/protected.d. This way, DNF 4 cannot uninstall itself, but DNF 5 can uninstall DNF 4, and likewise (given a similar change in DNF 5), DNF 5 cannot uninstall itself, but DNF 4 can uninstall DNF 5. Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221905 Related: https://bugzilla.redhat.com/show_bug.cgi?id=2221907 = changelog = msg: Allow dnf to be removed by DNF 5 type: enhancement
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.
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. We unprotected
dnf
to allow this upgrade, but that solution isn't perfect; DNF 5 should be able to remove python3-dnf[1] and DNF 4 should not be able to remove DNF without installing DNF 5. @m-blaha proposed "implementing a hard-coded self-protection for each package manager", i.e. adding back the hardcoded protection ofdnf
andpython3-dnf
in DNF 4 and adding a protection ofdnf5
in DNF 5. So if we want to do this, it seems we would need to allow obsoletion of protected packages to allow DNF 4 to obsoletednf
withdnf5
.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. I think this PR's approach is decent enough for our purposes.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2221905