Rawhide: symlink to /usr/lib/debug/usr/lib64/bfd-plugins/libdep.so-2.40-7.fc39.x86_64.debug broken

[gursewak1997]

Describe the bug

With the upgrade from kexec-tools 2.0.26-3.fc38 -> 2.0.26-4.fc39, we are seeing that the symlink to /usr/lib/debug/usr/lib64/bfd-plugins/libdep.so-2.40-7.fc39.x86_64.debug cannot be validated.

[2023-05-16T13:06:29.748Z] May 16 13:06:28 qemu0 kola-runext-validate-symlinks[2078]: + [[ false == \f\a\l\s\e ]]

[2023-05-16T13:06:29.748Z] May 16 13:06:28 qemu0 kola-runext-validate-symlinks[2078]: + fatal 'Error: /usr/lib/debug/.build-id/36/96626d3b4b74691ca6d10f86971e546755f6ba.debug symlink to /usr/lib/debug/usr/lib64/bfd-plugins/libdep.so-2.40-7.fc39.x86_64.debug which does not exist'

Expected behavior

The symlink to /usr/lib/debug/usr/lib64/bfd-plugins/libdep.so-2.40-7.fc39.x86_64.debug should exist

Actual behavior

The symlink to /usr/lib/debug/usr/lib64/bfd-plugins/libdep.so-2.40-7.fc39.x86_64.debug is broken

System details

[rawhide][x86_64] 39.20230516.91.0

Additional information

Bugzilla issue: https://bugzilla.redhat.com/show_bug.cgi?id=2208360

[travier]

rpm -qf /usr/lib64/bfd-plugins/libdep.so
binutils-2.39-9.fc38.x86_64

[travier]

It's in there:

https://koji.fedoraproject.org/koji/rpminfo?fileStart=50&rpmID=34277234&fileOrder=name&buildrootOrder=-id&buildrootStart=0#filelist

[travier]

As we don't ship any debug info in FCOS, I suggest that we:

• Skip /usr/lib/debug entirely for the check
• Add a post-process script in our manifests that entirely removes this folder and re-creates it empty

This should work around those failures that are not big enough for us to spend time on.

As Colin said in coreos/fedora-coreos-config#2427 (comment), this should fail in Fedora CI.

[dustymabe]

More info: binutils is a new dependency of kdump that got brought in with the kexec-tools 2.0.26-3.fc38 -> 2.0.26-4.fc39 transition, which is why we are seeing this now.

[dustymabe]

As we don't ship any debug info in FCOS, I suggest that we:

• Skip /usr/lib/debug entirely for the check

I think that's fair.

• Add a post-process script in our manifests that entirely removes this folder and re-creates it empty

I'm not sure I agree. I think we should do less modifying the original package delivered contents. What we could/should do is make sure no packages we include deliver files there (I assume it is some violation of packaging guidelines?).

[travier]

https://src.fedoraproject.org/rpms/kexec-tools/c/ea7be0608ed719cc1cb134ecf6ef51a4b7e9f104?branch=rawhide

[travier]

• Add a post-process script in our manifests that entirely removes this folder and re-creates it empty

I'm not sure I agree. I think we should do less modifying the original package delivered contents. What we could/should do is make sure no packages we include deliver files there (I assume it is some violation of packaging guidelines?).

Agree that this should be caught at a higher level, in Fedora infra / CI. Until that happens, I think it's a good example of a test where it should be a warning, but not a failure, as we can just workaround it until that happens properly in Fedora.

[dustymabe]

For this particular issue the bug mentions that this should be fixed in binutils-2.40-9.fc39 (hopefully in the next rawhide compose).

[travier]

I think we should have kexec-tools only recommend binutils as it's only for UKI support and we don't support that for now.

Filed: https://src.fedoraproject.org/rpms/kexec-tools/pull-request/14