which yum repos to use when package layering?

[dustymabe]

A user is hitting an issue which I think could be related to a bug I'm seeing. Basically the bug (I think) is that package layering is using yum repo files from the currently booted deployment rather than the deployment that is the target of the layered operation. That could be confusing so here is an example.

1. boot fedora rawhide atomic host
2. rebase to fedora 28 atomic host (no reboot): rpm-ostree rebase fedora/28/x86_64/atomic-host
3. try to package layer an rpm rpm-ostree install htop
4. you see the rpm that gets installed into the pending f28 deployment is actually an f29 rpm (from rawhide) and the repos used were rawhide repos.

# rpm-ostree status -v 
State: idle
AutomaticUpdates: disabled
Deployments:
  ostree://fedora-atomic:fedora/28/x86_64/atomic-host
                   Version: 28.20180816.1 (2018-08-16 15:03:58)
                BaseCommit: c6b1e97b93424c260baa98518277d87f7f4ebf036c09a9a0aeb7097c33c2099c
                            └─ repo-0 (2018-08-16 14:51:33)
                            └─ repo-1 (2018-04-25 04:27:32)
                    Commit: af917bdb539dc7c48c15c786088b960f32790f886601cc209269d8a808cbbfab
                            └─ rawhide-modular (2018-08-25 08:07:19)
                            └─ rawhide (2018-08-26 07:58:36)
                    Staged: no
                 StateRoot: fedora-atomic
              GPGSignature: 1 signature
                            Signature made Thu 16 Aug 2018 03:05:03 PM UTC using RSA key ID E08E7E629DB62FB1
                            Good signature from "Fedora 28 <fedora-28@fedoraproject.org>"
           LayeredPackages: htop

● ostree://fedora-atomic:fedora/rawhide/x86_64/atomic-host
                   Version: Rawhide.20180826.n.0 (2018-08-26 09:03:49)
                BaseCommit: 0bde7efe3e6e7e05009072dcfa4a451345dbb5034d70a2f2361f7eeeb49f6a21
                            └─ repo-0 (2018-08-26 07:58:36)
                    Commit: f628a18b31825c5cb1e4aedc74a60e395f7771d1a1f8ed83fad41bc2408b1253
                            └─ rawhide-modular (2018-08-26 07:59:42)
                            └─ rawhide (2018-08-26 07:58:36)
                 StateRoot: fedora-atomic
              GPGSignature: 1 signature
                            Signature made Sun 26 Aug 2018 09:03:59 AM UTC using RSA key ID EF3C111FCFC659B9
                            Can't check signature: public key not found
           LayeredPackages: htop

In this case layering htop worked fine because the package from rawhide had no conflicting dependencies but in cases like the user I mentioned above it can cause issues. What is the right thing to do here?

[dustymabe]

forgot to add: rpm-ostree-2018.7-1.fc29.x86_64

[jlebon]

Ahh OK, this is tricky.

So today, rpm-ostree uses the /etc/yum.repos.d/ of the booted deployment when it fetches packages. But it uses the releasever of the pending deployment. I think the underlying problem here is that rawhide repo URLs are completely different than a simple $releasever substitution (in fact, it doesn't even use $releasever).

Why do we use the /etc/yum.repos.d/ of the booted deployment? Because that's what you currently have control over. Otherwise, e.g. installing packages from a new repo (e.g. rpmfusion) would require two reboots.

Not sure offhand of an easy way to fix this other than recommending a reboot of the repo files.

[cgwalters]

For rawhide, see https://pagure.io/releng/issue/7445

[dustymabe]

Because that's what you currently have control over

could we possibly specify repos on the command line?

For rawhide, see https://pagure.io/releng/issue/7445

so would ^^ solve this problem?

[jlebon]

so would ^^ solve this problem?

If I understand what's being proposed there, yes it should.

[mildred]

You don't need a reboot. If rpm-ostree is able to read .repo files from an ostree commit, package layering just needs to happen in two steps:

• first: layer packages that contains .repo files
• next: layer all the other packages

I suppose the distinction could not happen automatically, and it might be necessary to specify when layering a new package, if it's defining new repositories (and thus must be stage 1) or if it is a regular package that comes after.

With this, we could also gain effortless rebase to new release. I just rebased my silverblue workstation from fedora 29 to 30, and I had this error from the rpmfusion repositories:

error: cannot update repo 'rpmfusion-free-updates': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

This is because it was using the fedora 29 repository files to layer packages on top of the fedora 30 update. I suppose I wouldn't have had this problem if rpm-ostree had used the repo files from fedora 30 instead (combined with the --install and --uninstall flags introduced in #711).