rpm: update config files for drop ins

[Luap99]

Ship the fedora overwrites as proper drop ins. This allows us to remove the fragile script to patch the files but also makes it much clearer that we can ship the real upstream default as main file and then only have small drop in files for the distro customization.

[Luap99]

cc @lsm5 @jnovy

untested at the moment, for upgrades I need to make sure we remove the old files from /etc/ but only if they were not modified by the user. If they were they should be kept.

[packit-as-a-service]

Packit jobs failed. @containers/packit-build please check.

[lsm5]

To retain the files only if they have been modified, we'll need this scriptlet before the %files section and also keep the 2 %dir lines.

 %posttrans
  # Restore user-modified config files from .rpmsave
  for file in \
      %{_sysconfdir}/containers/policy.json \
      %{_sysconfdir}/containers/registries.conf \
      %{_sysconfdir}/containers/registries.conf.d/000-shortnames.conf \
      %{_sysconfdir}/containers/registries.d/default.yaml \
      %{_sysconfdir}/containers/registries.d/registry.redhat.io.yaml \
      %{_sysconfdir}/containers/registries.d/registry.access.redhat.com.yaml
  do
      if [ -f "${file}.rpmsave" ]; then
          mv "${file}.rpmsave" "${file}"
      fi
  done

We can test this once there are packit scratch builds.

@jnovy PTAL as well.

[lsm5]

If we want user-modified files to remain after rpm upgrade, we should keep these dirs.

[Luap99]

ok I dropped them because they were no longer created so rpm failed. I guess I just need to keep creating them in the install section?

[lsm5]

I think so. Another untested option would be to list the dirs as %ghost %dir %{_sysconfdir}..., so rpm would ignore those dirs if they exist, but not sure if that'd affect the %posttrans. Could leave that for followups / if we notice any additional issues after this goes in.

[Luap99]

@lsm5 Thank you, this did the trick when I tested on a local VM. The unmodified policy.json is gone, while the modified registries.conf is kept.

RPM reports

[RPM] /etc/containers/registries.conf saved as /etc/containers/registries.conf.rpmsave

And then the posttrans moved it back successfully. I guess this means the theoretically there is a small window where podman might get run and the registries.conf.rpmsave is not yet moved back so it runs without the proper config. Given the non atomic nature that is unavoidable and I doubt it would be encountered by anyone.

[Luap99]

For the record it would likely be good to have #753 merged and vendored into podman first as otherwise the code will not yet be ready to read the files there which could cause troubles on podman-next so I moving this back to draft but otherwise this should be good to go pending review.

[mtrmac]

ACK. I’ll defer to up-to-date RPM experts on everything.

[mtrmac]

Also, we have talked about preventing the use of the updated c-common with old Podman/Buildah/Skopeo.

If that will happen, where should that happen? I think Conflicts: … < … in this package is a natural place.

[Luap99]

Also, we have talked about preventing the use of the updated c-common with old Podman/Buildah/Skopeo.

If that will happen, where should that happen? I think Conflicts: … < … in this package is a natural place.

Yes I think that is fair, have we decided on what the next skopeo/buildah versions are?

Looking at podman-next repo If at least the buildah and skopeo versions there are wrong (older than even the latest release)
https://copr.fedorainfracloud.org/coprs/rhcontainerbot/podman-next/packages/

So I assume if I would add a conflict right now here that would break podman-next packages?

Conflicts: podman < 6
Conflicts: buildah < 1.44
Conflicts: skopeo < 1.23

would this be correct?

[Luap99]

looking at the current spec file it included the epoch, is that required for Conflicts to work? the podman-next repo contains a much higher epoch so would that always be newer than?

[lsm5]

Looking at podman-next repo If at least the buildah and skopeo versions there are wrong (older than even the latest release) https://copr.fedorainfracloud.org/coprs/rhcontainerbot/podman-next/packages/

So I assume if I would add a conflict right now here that would break podman-next packages?

Conflicts: podman < 6
Conflicts: buildah < 1.44
Conflicts: skopeo < 1.23

would this be correct?

We should include the Epoch as well and have it conflict on the Epoch:Version as it exists on official Fedora. The podman-next Epoch is 100+ something so those won't be affected.

[lsm5]

cc @inknos @jankaluza

[lsm5]

This works.

PTAL as well @inknos @jankaluza @jnovy .

[jnovy]

Is this still relevant as this is RHEL registries?

[Luap99]

I think I should just drop the comment I guess

[danishprakash]

off-topic: would it be helpful to add drop-in support for mounts? base mounts.conf currently has /usr/share/rhel/secrets:/run/secrets, which, even though it's a no-op for non-rhel distributions (iiuc), fits better as a drop-in, much in line with what this PR implements.

[Luap99]

that was not in scope for our config file rewrite. I have not seen user complains about it so I never considered it.
If you want to file an issue for it sure, but it won't be in time for 6.0. Adding drop ins later for this should be safe enough I guess as it would not be a breaking change for mounts.conf.

[mtrmac]

ACK.

(Marking as approved to unblock merging, but I’ll fully defer to experts on reviews / timing.)