#138 automatically adding new packages when upgrading
Opened 8 months ago by chrismurphy. Modified 2 months ago

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

  • Is this something that can be and should be solved in Workstation edition?

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.

  • Is this adequately addressed by Silverblue/ostree?

Does this block #119 or is it a standalone issue?

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

8 months ago

At meeting:

  • this is probably a dnf bug, @chrismurphy will file one
  • workaround, add weak dependency: supplements fedora-release-workstation

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

8 months ago

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.

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

6 months ago

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

6 months ago

Discussed at today's meeting.

  • Action: Neal to follow up with dnf maintainers
  • Action: Michael to create list of Recommends in fedora-release-workstation package containing packages that should be installed on upgrade, as a workaround until https://bugzilla.redhat.com/show_bug.cgi?id=1814306 is fixed

Metadata Update from @catanzaro:
- Issue untagged with: meeting

6 months ago

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.

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.

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

6 months ago

@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.

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

5 months ago

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

Action: Neal to discuss with dnf developers

Metadata Update from @catanzaro:
- Issue untagged with: meeting

5 months ago

Metadata Update from @chrismurphy:
- Issue set to the milestone: Fedora 34 (was: Fedora 33)

3 months ago

Login to comment on this ticket.

Metadata