Comments
carlwgeorge
The duplication of /usr/bin/lsb_release was identified during the package review, and the appropriate Conflicts directive was added, per the conflicts policy.
There are currently zero issues in the upstream issue tracker. If you believe it to be buggy, please back up that claim by filing bugs with the upstream.
This state of this package is sufficient to be pushed to the stable repo.
The duplication of /usr/bin/lsb_release was identified during the package review, and the appropriate Conflicts directive was added, per the conflicts policy.
There are currently zero issues in the upstream issue tracker. If you believe it to be buggy, please back up that claim by filing bugs with the upstream.
This state of this package is sufficient to be pushed to the stable repo.
The duplication of /usr/bin/lsb_release was identified during the package review, and the appropriate Conflicts directive was added, per the conflicts policy.
There are currently zero issues in the upstream issue tracker. If you believe it to be buggy, please back up that claim by filing bugs with the upstream.
This state of this package is sufficient to be pushed to the stable repo.
Works as expected.
Recommending software that is required to meet LSB compliance is not correct. The entire point of the LSB is to guarantee the presence of specific commands and libraries. Skipping required items is setting us up for missed expectations with users.
I also do not have time to fix all the problems that exist with this package, but I'm not the maintainer of the package. You started the work of updating the package to LSB 5.0, but that work is incomplete. These issues should be worked out in Fedora before being added to EPEL 9. When it is added to EPEL 9, it should be with the correct dependencies. Any missing dependencies should be made available, not skipped. If the package can't be done correctly, then it shouldn't be added to EPEL 9 at all, and furthermore it's existence in Fedora should be re-evaluated as well.
If the only goal is to provide the lsb_release command, then maintaining a full redhat-lsb package is probably not worth the effort. Instead, consider using this minimal lsb_release fork, which was recently packaged as lsb_release in Fedora and EPEL 9. The upstream for redhat-lsb effectively doesn't exist anymore (unmaintained for over 8 years), so according to policy it should be retired.
It seems this extension change upstream to no longer permit loading a shared gschemas.compiled file, which is how it worked previously. I'm working with them for a fix.
https://github.com/pop-os/shell/issues/1649#issuecomment-1778491814
According to the spec, the pax command is still required to be LSB 5.0 conforming. Therefore the requires is correct, and the solution is to require a package that provides the pax command. Fedora does that by requiring spax. Nothing in RHEL 9 or EPEL 9 currently provides pax, so you'll need to resolve that. spax is part of the star spec file, which is in RHEL 9, but the spax subpackage is not shipped. You can request that from the RHEL maintainer, or create a star-epel package to ship the missing subpackages.
There are several other commands in this table that are part of LSB 5.0 conformance that are missing as requires, which also applies to the Fedora package.
- infocmp
- install_initd
- remove_initd
- tic
- tput
That's just from the table of commands for the core module. Please review that as well as the commands and libraries needed for all the LSB modules.
None of the points I brought up have been addressed. Therefore, I don't think it's appropriate to push the update to stable in this state.
Just like any other package, if you have a requirement that isn't available then you should make it available, not skip it. If LSB requires something (even if by policy and not in code) then silently omitting it will break user expectations and defeat the whole purpose of the package.
In the case of EPEL, making the dependency available may be done a few different ways. Some packages like qt and perl-B-Lint are not shipped in RHEL 9 at all and thus can be added to EPEL 9 directly (see this guide). Some packages like spax come from a SRPM that is in RHEL 9, but are not themselves shipped in RHEL 9. In those cases you can either file a request to have RHEL add it, and/or add an EPEL-only package to provide the missing subpackages (see this guide).
In the case of the redhat-lsb subpackages, if you're not willing/able to make the missing dependencies available, it would be better to conditionalize the whole subpackage than to ship it with a skipped dependency. For example, if you decide that qt isn't worth the effort, you can conditionalize the desktop subpackage (and the top level requires that pulls it in) to only apply to Fedora.
As an aside, conditionalizing libxcrypt-compat for Fedora is unnecessary, because that package is in RHEL 9.
Having the fix be to conditionally require those dependencies seems odd to me. Either they are required by the package or they're not. If they're not required, they should not be required on Fedora either. Are they old dependencies that are no longer required? If so are there more that need to be pruned? Are they actually required and certain behavior is not functional without them? There is no %check in the spec file to ensure the software is functional. Would they make more sense as Recommends? If they are required, the proper fix is to request those dependencies be added to EPEL, not merely silently ignored.
Please don't push this to stable until there are answers to these questions, preferably noted in the spec file with comments so that future maintainers are able to better maintain the package.
Most of the packages in this update are not installable on RHEL 9.
- redhat-lsb-core:
Error:
Problem: conflicting requests
- nothing provides spax needed by redhat-lsb-core-5.0-0.2.20231006git8d00acdc.el9.x86_64
- redhat-lsb-desktop:
Error:
Problem: conflicting requests
- nothing provides qt(x86-64) needed by redhat-lsb-desktop-5.0-0.2.20231006git8d00acdc.el9.x86_64
- nothing provides qt-x11(x86-64) needed by redhat-lsb-desktop-5.0-0.2.20231006git8d00acdc.el9.x86_64
- redhat-lsb-languages:
Error:
Problem: conflicting requests
- nothing provides perl(B::Lint) needed by redhat-lsb-languages-5.0-0.2.20231006git8d00acdc.el9.x86_64
- nothing provides perl(Class::ISA) needed by redhat-lsb-languages-5.0-0.2.20231006git8d00acdc.el9.x86_64
- nothing provides perl(File::CheckTree) needed by redhat-lsb-languages-5.0-0.2.20231006git8d00acdc.el9.x86_64
- nothing provides perl(Pod::LaTeX) needed by redhat-lsb-languages-5.0-0.2.20231006git8d00acdc.el9.x86_64
- nothing provides perl(Pod::Plainer) needed by redhat-lsb-languages-5.0-0.2.20231006git8d00acdc.el9.x86_64
- redhat-lsb: requires redhat-lsb-languages
- redhat-lsb-cxx: requires redhat-lsb-core
- redhat-lsb-printing: requires redhat-lsb-core
Quoting the actual policy:
Provenpackagers lend a hand when help is needed, always with a desire to improve the quality of Fedora.
Help was needed and I provided it. This improved the quality of EPEL, which is part of the Fedora project.
Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, irc or email.
- libptytty pull request (merged by you)
- rxvt-unicode pull request (merged by the other maintainer of the package)
They should be careful not to change other people’s packages needlessly and try to do the minimal changes required to fix problems
I performed the minimum changes necessary to undo your policy-breaking change. In no way, shape, or form was me resolving this issue an abuse of proven packager permissions. Next time, follow EPEL policy so I don't have to step in to clean up your mess.
Please see the following pull requests:
- https://src.fedoraproject.org/rpms/rxvt-unicode/pull-request/2
- https://src.fedoraproject.org/rpms/libptytty/pull-request/2
Merging these and building them for EPEL 7 will resolve this situation.
If you read the EPEL incompatible upgrades policy, you'll see that security updates are explicitly mentioned as good justification for performing an incompatible upgrade. But security justification doesn't absolve the maintainer from following the process. There are important notification steps that are involved. Alternatively, it may make more sense to retire a package from EPEL outright, which has its own process with notification steps.
This is the policy that all EPEL packagers are required to follow. If you disagree with the policy, you are welcome to submit changes to the policy to be more to your liking, which will be reviewed by the EPEL Steering Committee.
The EPEL updates policy states that updates with major changes to user experience are to be avoided. This update does not appear to follow that policy. Please avoid such disruptive updates for EPEL packages in the future. If it is unavoidable, please follow the incompatible upgrades policy.
This update increased the library soname from libclamav.so.9 to libclamav.so.11. This is considered an incompatible upgrade and is not normally allowed by EPEL policy. Please avoid bumping library sonames in EPEL updates in the future. If it is unavoidable, please follow the incompatible upgrades policy.
I've rebuilt the two affected packages, c-icap-modules and librpminspect, in a new update.
I got a little ahead of myself on this one, and the new python3-spnego+kerberos subpackage fails to install.
Error:
Problem: conflicting requests
- nothing provides python3.12dist(krb5) >= 0.3 needed by python3-spnego+kerberos-0.9.2-1.fc40.noarch from brew-106054122
- nothing provides python3.12dist(krb5) >= 0.3 needed by python3-spnego+kerberos-0.9.2-1.fc40.noarch from fedora-40-buildroot
I've gotten a new python-krb5 package reviewed, so this update should fix the issue.
It's not possible to unpush a bodhi update that has gone to stable.
As a last resort, it is possible for releng to manually untag the corresponding koji build to remove the package from the repos. The downside is that leaves us in an inconsistent state where bodhi doesn't match the state of the repo. It is highly preferred to create new update to solve the problem, if possible.
The duplication of
/usr/bin/lsb_releasewas identified during the package review, and the appropriate Conflicts directive was added, per the conflicts policy.There are currently zero issues in the upstream issue tracker. If you believe it to be buggy, please back up that claim by filing bugs with the upstream.