Allow obsoletion of protected packages #733
Conversation
|
Could you please put the details in the commit message instead of referring to another PR? |
evan-goode
force-pushed
the
evan-goode/allow-obsolete-protected
branch
from
ddd2b54
to
e4c3f3d
Compare
Thanks, I added some details to the commit message. |
|
This change might be problematic, because you can remove protected package in two steps |
|
I didn't find any particular reason - the obsoleted packages are just there from the beginning. Here is the forefather of the current implementation - rpm-software-management/yum@ab34fab . And here is how the protected packages yum plugin looked like when it was moved from plugins to core: rpm-software-management/yum-utils@610ef70 |
evan-goode
force-pushed
the
evan-goode/allow-obsolete-protected
branch
from
e4c3f3d
to
b172303
Compare
|
Ah, this change would unfortunately break the way we protect the running kernel from being removed. The failing test is: I think it would be best to find another way to allow upgrading DNF 4 to DNF 5 while keeping DNF 4 "protected". |
evan-goode
force-pushed
the
evan-goode/allow-obsolete-protected
branch
from
b172303
to
934fb56
Compare
|
Per @j-mracek's recommendation, I am reopening this and treating the running kernel as a special case. So now with this patch, obsoleting protected packages is allowed, except for the running kernel, which cannot be removed or obsoleted. I think this approach is reasonable; there should be some way for the distribution to "unprotect" packages. One use case that might be broken by this change is a user protecting a package to prevent it from being obsoleted by something else in the distribution. But that's a problem better suited for |
evan-goode
force-pushed
the
evan-goode/allow-obsolete-protected
branch
from
934fb56
to
71e82c4
Compare
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
force-pushed
the
evan-goode/allow-obsolete-protected
branch
from
71e82c4
to
799cc1c
Compare
a3464eb
libdnf5 companion to rpm-software-management/libdnf#1610