Hide Forgot
Hello, please see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6RO5HL5GTPALQO4XB746OSTZYG334DAN/ for context and discussion. tl;dr: 1. fedora-repos-modular are installed when upgraded to Fedora 33 2. `dnf autoremove` removes the package because it is only installed as a dependency (via obsoletes) and no other package requires it 3. the intention is to keep the package unless the user explicitly removes it I'd like to ask if dnf system-upgrade could do: if fedora-repos-modular is installed: dnf mark install fedora-repos-modular else: do nothing I am assuming it is not possible to do this from a scriptlet, but do correct me if that is possible.
We'll look into reinstalling installed comps groups. That would install and mark the package with the "group" reason. Would that work for you?
It would, but won't there be undesired side effects? Like re-installing intentionally removed packages?
That's right. On the other hand, the currently installed package fedora-repos-modular was installed as a dependency, therefore not intentionally and we're looking for a way how to make in user/group installed without running dnf during dnf/rpm transaction. Or are you referring to different packages than fedora-repos-modular that would be installed back? That is actually requested as a feature in bug#1814306. We'd probably make the behavior configurable.
I am referring to any packages explicitly removed by the user/admin. E.g. if I run `sudo dnf remove fedora-repos-modular` I don't expect it to be reinstalled upon the next upgrade. The same applies to any other package I've removed. See for example https://bugzilla.redhat.com/show_bug.cgi?id=1845562#c4
I'm not sure if we have any other options. It's definitely not a good idea to run dnf while it runs already to mark the packages. Couldn't we document it in the Fedora upgrade guide? That would be the simplest solution with no hacks.
We can document this in common bugs as well. I just thought the upgrade mechanism would be able to do this kind of things.
Not sure if we are going in right direction, because the problem is caused by change in packaging of fedora-repos or related packages, but the solution is searched in general software-management-tools (the fix for system-upgrade will be not sufficient, because PackageKit and other tools will require it). From dnf tool perspective we can provide a general mechanism how to handle such a operation. On the other hand, the particular fix must be maintained by distribution and it should not be a part of DNF or DNF plugins. From practical point of view the revert of removal of require for fedora-repos-modular will be the best way how to resolve the issue. What do you think?
> From dnf tool perspective we can provide a general mechanism how to handle such a operation. On the other hand, the particular fix must be maintained by distribution and it should not be a part of DNF or DNF plugins. Works for me. > From practical point of view the revert of removal of require for fedora-repos-modular will be the best way how to resolve the issue. What do you think? Well obviously, if we abandon the entire Fedora change and revert it, the problem will be gone, but I'd rather find an actual solution to the problem.
> the fix for system-upgrade will be not sufficient, because PackageKit and other tools will require it To clarify: I wanted to get this solved in dnf system upgrade first (or at least talk about it) and later also ask PackageKit, however since PackageKit seems abandoned, I figured here there will be a better chance to move somewhere.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Here is a PR that adds upgrading of groups and environments into system-upgrade: https://github.com/rpm-software-management/dnf-plugins-extras/pull/183 It still needs to be tested, but the group upgrade should not install back packages that were explicitly removed or excluded during the groups installation.
FEDORA-2020-b40fc174b5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b40fc174b5
FEDORA-2020-5d9f0ce2b3 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5d9f0ce2b3
FEDORA-2020-b40fc174b5 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b40fc174b5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b40fc174b5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5d9f0ce2b3 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5d9f0ce2b3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5d9f0ce2b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5d9f0ce2b3 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-b40fc174b5 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.