Allow obsoletion of protected packages #1610
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
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.
evan-goode
force-pushed
the
evan-goode/f39
branch
from
8f8d3ee
to
8c005d2
Compare
|
Reopening, see rpm-software-management/dnf5#733. |
evan-goode
force-pushed
the
evan-goode/f39
branch
from
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.
evan-goode
force-pushed
the
evan-goode/f39
branch
from
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.
evan-goode
merged commit 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
dnfto 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 ofdnfandpython3-dnfin DNF 4 and adding a protection ofdnf5in 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 obsoletednfwithdnf5.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