bootable-rpm-ostree: move to s390utils-core to get rid of perl dependency on mainframe

[jcajka]

SSIA

[jcajka]

This will resolve the issue #341 from the FCOS perspective.

[jlebon]

Can you provide a sentence or two in the commit message about what the difference between the two packages are at the functional level? Are we losing any important functionality?

This will resolve the issue #341 from the FCOS perspective.

Nice, so I think we can add "Closes: #341" too, right?

[jcajka]

Can you provide a sentence or two in the commit message about what the difference between the two packages are at the functional level? Are we losing any important functionality?

AFAIK none from practical perspective. @sharkcz do I remember that correctly?
From the s390utils side it means we are loosing cpi and genprotimg tools.

This will resolve the issue #341 from the FCOS perspective.

Nice, so I think we can add "Closes: #341" too, right?

Yeah, I have forgotten about it. Fixed it now.

[sharkcz]

cpi is in core, so the OS will correctly set its identification in the hypervisor, we are losing various sysadmin tools that are not required for booting the system

[Prashanth684]

Unfortunately this change breaks RHCOS.

@sharkcz do you know when we will have this change as part of rhel-8.3 ?

@jlebon @jcajka in the meantime should this be backed out or is there a way to override it for rhcos and use this for fcos alone ?

[cgwalters]

We can pretty easily explicitly install s390utils-base in the rhcos manifest right?
(If you do a PR, can you explain why it breaks?)

[Prashanth684]

We can pretty easily explicitly install s390utils-base in the rhcos manifest right?
(If you do a PR, can you explain why it breaks?)

right yes..it can be specified...but still this change has to be excluded for s390x somehow. the bootable-rpm-ostree.yaml is included in ignition-and-ostree.yaml which is included in the manifests. these need to separated out somehow.

[cgwalters]

Is the problem that the package doesn't exist yet in RHEL 8.3? If so right, there's not a clean way to handle this right now other than splitting things up in FCOS as you said - rpm-ostree doesn't have anything like "try finding this package A but if not use this other one B" or distro version conditionals. We could potentially invent that though.

[sharkcz]

Unfortunately this change breaks RHCOS.

@sharkcz do you know when we will have this change as part of rhel-8.3 ?

The "core" split from "base" won't be in RHEL 8.3, it's a new feature coming to 8.4.

[Prashanth684]

Is the problem that the package doesn't exist yet in RHEL 8.3? If so right, there's not a clean way to handle this right now other than splitting things up in FCOS as you said - rpm-ostree doesn't have anything like "try finding this package A but if not use this other one B" or distro version conditionals. We could potentially invent that though.

yup...these changes need to be backported to RHEL afaik...but @sharkcz might know better about that. I was wondering if for now we could reference bootable-rpm-ostree.yaml explicitly in the manifests rather than include it in ignition-and-ostree.yaml ? that way in the rhcos manifest i can exclude that file and add the relevant bits in a package-s390x

[jlebon]

Could we just change the request to /usr/sbin/zipl? That should pull the right package in both cases right?

[sharkcz]

Could we just change the request to /usr/sbin/zipl? That should pull the right package in both cases right?

yes, sounds like a good solution

[Prashanth684]

Could we just change the request to /usr/sbin/zipl? That should pull the right package in both cases right?

yeah that's neat! thanks @jlebon !

[jlebon]

#775

[jcajka]

@Prashanth684 sorry I haven't been aware that rhcos is on so aggressive inheritance, AFAIK it hasn't been in the past(I assumed this will land in 8.4, but more in 8.5 time frame on rhcos side). I will check with you in future.

[Prashanth684]

@Prashanth684 sorry I haven't been aware that rhcos is on so aggressive inheritance, AFAIK it hasn't been in the past(I assumed this will land in 8.4, but more in 8.5 time frame on rhcos side). I will check with you in future.

no worries @jcajka ! turned out easy enough to fix this time, but yes in the future I think we need to make sure any new packages which are part of Fedora probably won't make it to the rhel releases as fast and maybe try to split that to be fcos specific.

[jlebon]

Follow-up to this: note that coreos-installer will be pulling back s390utils-base because of fdasd in https://src.fedoraproject.org/rpms/rust-coreos-installer/pull-request/14#comment-63341. Is it easy to move that to s390utils-core too? (Or maybe we need a clearer "-base" and "-scripts" distinction or something to separate out all the bits which pull in Perl.)

[sharkcz]

The definition of s390utils-core is "a bare minimum of tools to be able to install a system and to boot an installed system", so moving fdasd to core meets the definition.

[sharkcz]

And yes, it's easy to move it.

[sharkcz]

OK, will be in s390utils-2.15.1-3 in a bit. If you need fdasd in RHEL builds too, then please file a bug there.

[bgilbert]

@sharkcz Thanks for moving fdasd. There's actually one more tool in -base that coreos-installer depends on: lszdev. Would it make sense to move that as well?

[sharkcz]

@sharkcz Thanks for moving fdasd. There's actually one more tool in -base that coreos-installer depends on: lszdev. Would it make sense to move that as well?

sure, makes sense, let me do a new build :-)