Comments
carlwgeorge
lsb_release has an explicit conflicts with redhat-lsb-core. You moved the /usr/bin/lsb_release file between subpackages without coordinating with the lsb_release maintainer. That is the problem here, not the existence of lsb_release. Both packages need the conflicts to follow policy, so at a minimum you need to add Conflicts: lsb_release to redhat-lsb. The nice thing to do would be to also send a pull request to the lsb_release package to update its conflicts statement to account for the change you made in redhat-lsb.
You also need to add a versioned conflicts between your subpackages to ensure they're upgraded together, because now redhat-lsb also has an implicit conflicts with earlier versions of redhat-lsb-core.
root@f40-container:~# rpm -qa | grep redhat-lsb
redhat-lsb-core-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-cxx-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-languages-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-printing-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-desktop-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-5.0-0.4.20231006git8d00acdc.fc40.x86_64
redhat-lsb-supplemental-5.0-0.4.20231006git8d00acdc.fc40.x86_64
root@f40-container:~# dnf update redhat-lsb
<snip>
Error: Transaction test error:
file /usr/share/man/man1/lsb_release.1.gz from install of redhat-lsb-5.0-0.7.20231006git8d00acdc.fc40.x86_64 conflicts with file from package redhat-lsb-core-5.0-0.4.20231006git8d00acdc.fc40.x86_64
You updating the description to indicate non-compliance is a good first step, but the output of /usr/bin/lsb_release still reports compliance. I've explained this repeatedly. Please stop arguing and just fix it.
You also need to stop with the inflammatory language like "offender" and "hijack". You're taking this personal and launching personal attacks on Neal. None of that is justified. You feel like redhat-lsb needs to stay around when most other people, including all of FESCo, agree that it should be retired. No one is forcing you to retire it, but you do need to make it comply with the packaging guidelines and the FESCo decision.
The concerns previous brought up here and in the FESCo ticket have not been fully addressed. I've seen no indication that a review has been done to identify all of the dependencies of the various LSB modules. Dependencies that could be added to EPEL are merely wrapped in conditionals. redhat-lsb has a implicit conflict with lsb_release, which is forbidden by the packaging guidelines. And worst of all, this package is still in violation of the FESCo decision.
According the the man page for lsb_release, the -v flag is used to "Display the version of the LSB specification against which the distribution is compliant." This package in it's current state reports that the distro is compliant with LSB 5.0.
root@rhel9-container:~# lsb_release -v
LSB Version: :core-5.0-amd64:core-5.0-noarch:cxx-5.0-amd64:cxx-5.0-noarch:desktop-5.0-amd64:desktop-5.0-noarch:languages-5.0-amd64:languages-5.0-noarch:printing-5.0-amd64:printing-5.0-noarch
This needs to be patched to report "n/a", which is what the minimal lsb_release package reports for that command.
That new vlc build fixed the installation issue, thanks.
This allows installing elf without downgrading LibRaw.
vlc is not installable.
Error:
Problem: package vlc-1:3.0.20-4.el9.x86_64 from epel-testing requires vlc-gui-qt(x86-64) = 1:3.0.20-4.el9, but none of the providers can be installed
- package vlc-gui-qt-1:3.0.20-4.el9.x86_64 from epel-testing requires vlc-plugins-base(x86-64) = 1:3.0.20-4.el9, but none of the providers can be installed
- conflicting requests
- nothing provides google-noto-sans-mono-vf-fonts needed by vlc-plugins-base-1:3.0.20-4.el9.x86_64 from epel-testing
- nothing provides google-noto-serif-vf-fonts needed by vlc-plugins-base-1:3.0.20-4.el9.x86_64 from epel-testing
Installing directly from koji shows me that these RPMs do correct the installability issue.
Installs correctly with the latest rpm-libs in CentOS 9, and a basic rpm.labelCompare check works as expected.
This update installs fine on RHEL, but doesn't resolve the issue in bug 2245057.
This update has been unpushed.
Per https://pagure.io/epel/issue/255#comment-883244, I'm going to unpush this for now.
The codename is indeed a flaw. Do you know of an example of the missing codename actually affecting third party software that requires the lsb_release command to be present? Please file an upstream bug about that if it's important to you.
The LSB version and short version being n/a is correct. "Display the version of the LSB specification against which the distribution is compliant." Fedora is not compliant, so n/a is the correct response. If anything, redhat-lsb is the one that is wrong here, because it's displaying an LSB version string when the system is not complaint.
I'll also reiterate the decision from the EPEL Steering Committee:
Fix the problems in this package first, and then EPEL Steering will discuss if this package will be allowed in EPEL or not.