Problem
There's presently no mechanism for system upgrades to install new standalone packages.
e.g. grubby and earlyoom are not installed by default in Fedora 30 or 31; but it's desired that both are installed in Fedora Workstation 32. Clean installs will have them due to their presence in fedora-comps. But since no package pulls the desired packages in as a dependency, and since dnf and PK's 'system upgrade' (ala distro-sync) only update installed packages, there's (apparently) no way to get such new packages installed.
Discussed this on #fedora-devel with nirik on IRC and it does seem, at least first and second glances, that this is the case.
Questions
The (historic) Workstation PRD says in part:
Robust Upgrades: Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation.
Does this block #119 or is it a standalone issue?
Presently, earlyoom will be on clean installs, and not upgraded systems.
I'm wondering if the general "upgrades aren't the same as clean install" issue is more of a FESCo issue? And this issue, #138, may also be improperly titled.
The Earlyoom feature proposal says it will apply to upgraded systems. Yet so far there isn't a way to do that.
The fsrim feature proposal likewise should apply to upgraded systems. But for different reasons (triggering upon release version change) this too may not be possible.
Also affects #127. Without a way to add 'zram-generator' on upgrades, users have to clean install to get the feature, or manually install and configure it.
Metadata Update from @chrismurphy: - Issue tagged with: meeting
At meeting:
Metadata Update from @chrismurphy: - Issue untagged with: meeting
Bug 1814306 - dnf system-upgrade doesn't install a newly added package from fedora-comps group
Bug 1811506 - fstrim.timer is not enabled on upgrades I'm stuck iterating this one too; I've asked about it on devel@ packaging@ and #yum and no replies.
I took a look at this and I think I got it to work correctly. See https://src.fedoraproject.org/rpms/util-linux/pull-request/4 (and https://bugzilla.redhat.com/show_bug.cgi?id=1811506#c11)
Status update: while the problem with particular examples in this issue were solved for F32 with a workaround, it's preferred to have a better long term solution as indicated in the related Taiga issue, subtask "F33 permanent solution for adding new packages when upgrading"
Use this issue to discuss the permanent approach, and rename it if necessary.
Metadata Update from @chrismurphy: - Issue set to the milestone: Fedora 33
Discussed at today's meeting.
Metadata Update from @catanzaro: - Issue untagged with: meeting
Here is an incomplete proposal for fedora-release-workstation Recommends. I've covered changes in workstation-product and gnome-desktop, but there are several other comps groups that need to be checked as well. Notice that the number of packages in quite significant, and the list is unwieldy and unmaintainable, even though it is not yet complete.
Sub-issues that need to be closed before closing this issue: #60, #66, #88, #142
EarlyOOM MR to remove the Supplements: https://src.fedoraproject.org/rpms/earlyoom/pull-request/2
EarlyOOM MR to remove the Supplements
Done.
BTW I'm specifically looking for feedback on this, because it turned out to be outrageously long, and it's not done yet. Some of the packages are sure to be redundant, but listing everything seemed like the only sane way to make sure we don't miss anything. It's also likely to result in GUI applications like gnome-photos appearing after upgrade.
@catanzaro We definitely need a better solution, this is going to be a nightmare otherwise.
Metadata Update from @catanzaro: - Issue tagged with: meeting-request
@ignatenkobrain replied to the swap on zram feature with a comment to reverse things around.
Instead of: Add Supplements: fedora-release-common to zram-generator to pull it in on upgrades.
Supplements: fedora-release-common
I would do it other way around just to keep logic sane. The fedora-release package is a "dummy" one, so there is no reason to "Supplement" it because it is meaningless, but having it other way around should be better.
I would do it other way around just to keep logic sane.
The fedora-release package is a "dummy" one, so there is no reason to "Supplement" it because it is meaningless, but having it other way around should be better.
Metadata Update from @chrismurphy: - Issue untagged with: meeting-request - Issue tagged with: meeting
Let's fix Comps instead. Recommends effectively become required on a Workstation system unless you disable weak deps entirely.
Agreed: we want system-upgrade to upgrade comps by running the equivalent of dnf group update Fedora Workstation
dnf group update Fedora Workstation
Action: Neal to discuss with dnf developers
Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1845562
Metadata Update from @chrismurphy: - Issue set to the milestone: Fedora 34 (was: Fedora 33)
dnf developers have proposed a pull request: https://github.com/rpm-software-management/dnf-plugins-extras/pull/183
It needs to be tested.
dnf-plugins-extra 4.0.12 has this functionality working.
Metadata Update from @chrismurphy: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.