Layered rpms do not get updated from repositories

[p1u3o]

Expected vs actual behavior

Layered rpms do not get updated. If a user installs the rpmfusion-free-release rpm (using this), it will not get updated when an update is available. Because rpmfusion-free-release updates are needed to support newer versions of Fedora, this rpm (and any packages from rpmfusion-free) will need to be removed and reinstalled for upgrades to succeed.

Expected:

Layered rpms get updated when an update is available in the configured repositories.

This also affects the Chrome rpm.

[jlebon]

This is how local packages behave. By default, if you do rpm-ostree install path/to/pkg.rpm, rpm-ostree will always pin to that specific RPM. If you obtain the RPM from the repo, it will keep pulling in newer versions from the repo.

Of course, for situations like rpmfusion, this can make for an awkward UX, because you're exactly trying to install an RPM which contains the repos from which to install RPMs. What I usually do for this is just rpm2cpio $pkg | cpio -id and import the repo files directly into /etc/yum.repos.d. The baseurls are versioned like the regular Fedora repos, though if you want to have them versioned, you'd then rpm-ostree install rpmfusion-free-release.

We could potentially develop a UX to make this use case easier. Something like rpm-ostree install --unpinned path/to/pkg.rpm? Have to think on it.

[p1u3o]

We could potentially develop a UX to make this use case easier. Something like rpm-ostree install --unpinned path/to/pkg.rpm? Have to think on it.

That would work.

I have an idea, perhaps when an rpm is passed to rpm-ostree override path/to/my.rpm it checks whether it's overriding the system, in which case it's the current override behaviour, or whether it's a new package, which would install the rpm pinned. rpm-ostree install path/to/my.rpm could then install unpinned rpms.

The baseurls are versioned like the regular Fedora repos, though if you want to have them versioned, you'd then

You also need the gpg key updates.

[jlebon]

I have an idea, perhaps when an rpm is passed to rpm-ostree override path/to/my.rpm it checks whether it's overriding the system, in which case it's the current override behaviour, or whether it's a new package, which would install the rpm pinned. rpm-ostree install path/to/my.rpm could then install unpinned rpms.

Maybe... although maintaining the separation between rpm-ostree install being strictly about adding packages onto the base whereas rpm-ostree override being strictly about modifying the base itself is I think an important concept.

I think as a first step, we should probably be more explicit about this behaviour in the output of rpm-ostree install path/to/pkg.rpm.

[kalev]

Yes, would be nice to do something about this. The layered local rpms never getting updated issue is causing quite a bit of trouble for people rebasing to a newer Fedora.

I think it would make sense to make them updatable by default, but maybe have a command line option to pin them to a specific version as is now.

[jlebon]

Yes, would be nice to do something about this. The layered local rpms never getting updated issue is causing quite a bit of trouble for people rebasing to a newer Fedora.

Are you speaking about the rpmfusion case specifically (and other repos-in-RPM setups)? Or people are hitting this in other situations?

I'm not sure if we'd want to break the current default behaviour for this, but I agree having a switch for this would make sense. In addition to more documentation, we could probably specifically catch this case by detecting that the RPM is dropping files in /etc/yum.repos.d and mention something about it.

[kalev]

Yes, it's mostly rpmfusion-...-release packages that are causing trouble, but it's a more general issue. rpmfusion release package have a dep on a specific version of fedora-release, so when rebasing to a new distro version, the rpmfusion-...-release dep on the fedora-release is no longer satisfiable and the whole rebase fails.

Normally (with dnf/regular fedora) this is solved by getting a new rpmfusion release package from the repos during the rebase -- but with rpm-ostree locally layered packages this doesn't work as they aren't updated via repos.

I'm not sure what's the use case for not updating the locally installed packages from repos. Is it to pin something to a specific version? Maybe it would be best to have an explicit way to pin layered (and not just locally installed) packages instead, and change the locally installed packages behaviour to get updates from repos?

I can imagine hitting this with a wide variety of third party repos, and frankly it's just confusing that they don't get updated. Let's say someone layers google-chrome (it's distributed as an rpm upstream, so it's natural to layer it) and then after a while they are super confused why it's not getting any updates.

[cgwalters]

I think the root issue here is more installing .repo files as RPMs is circular and awkward and should have better first class support from the package system. In fact, much like how OSTree remotes work.

[p1u3o]

A specific tool for managing additional repos would solve most use cases including adding coprs and Google Chrome (although, imho a Flatpak would be preferable for many reasons).

You would need to somehow handle GPG key updates though.

[junjieyuan]

Because of Chrome's rpm file contains an rpm repo file, so you can uninstall then reinstall chrome to upgrade.

After do this, chrome can be upgraded when have new version. (LocalPackages -> LayeredPackages)

rpm-ostree install /path/to/chrome.rpm  # This command install local rpm file.
reboot
rpm-ostree uninstall google-chrome-stable  # Uninstall chrome (in new deplyment). But current deplymont still hava chrome repo file.
rpm-ostree install google-chrome-stable  # Install from Chrome's repo.
reboot

[travier]

See also https://discussion.fedoraproject.org/t/simplifying-updates-for-rpm-fusion-packages-and-other-packages-shipping-their-own-rpm-repos/30364

[travier]

Copy pasting here for reference the suggestion to work around the issue of packages shipping with their own repo files, with RPM Fusion repos as example:

# Install RPM Fusion repos
$ sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
$ reboot

# Replace the versioned local packages by overlayed packages from the repo
$ sudo rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
$ reboot

[mtalexan]

See also https://discussion.fedoraproject.org/t/simplifying-updates-for-rpm-fusion-packages-and-other-packages-shipping-their-own-rpm-repos/30364

From the discussion this sounds like it's unresolvable by either rpm-ostree or by rpmfusion.

As is standard practice for all distro package managers, a generic name like rpmfusion-free-release (a "meta" package) is used to reference the latest version of a package rather than a fixed version of that package. Since there's no way to install a "meta" package via a direct rpm installation (that I know of), there's no way to do an initial install of rpmfusion that tracks the rpmfusion-free-release and rpmfusion-nonfree-release "meta" packages in a single installation step for as long as a manual rpm installation is required. The "meta" package needs to be in a repo, and the rpmfusion-free-release and rpmfusion-nonfree-release are only available in the rpmfusion repos themselves, so you have to do a manual rpm installation to get access to the repo first, then you can switch to track the "meta" package in that repo.

Theoretically the "better"/alternative installation instructions might be:

1. CLI Command for manually adding rpmfusion repos
2. CLI commmand for manually adding rpmfusion keys
3. "meta" package installation instructions