redhat-lsb 5.0 with new source location
Recommends the software which is not available on epel
Add packages description:
This package is not compliance with LSB, because various components are missing from Fedora or EPEL, so compliance is not possible. Fedora or EPEL explicitly declines add support the missing components from LSB 5.0 or earlier because these components are very outdated and have been removed from the repositories and possibly replaced with new ones. This package tries its best to comply with the LSB. Hoping to be helpful and continue to support the LSB project and software that uses it
Please login to add feedback.
This update has been submitted for testing by sergiomb.
This update's test gating status has been changed to 'ignored'.
Most of the packages in this update are not installable on RHEL 9.
This update has been pushed to testing.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
sergiomb edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by sergiomb.
Fixed
This update has been pushed to testing.
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 asRecommends
? 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.
They should be required , but if they not exist in repo what we can do ? , packages redhat-lsb-desktop only have 2 empty files, to indicate what version and arch of lsb-desktop are supported [2] and the rest is Requires [1] if we don't have qt4 on el9 , we can't require it. But where I have it, I require it, to be the most accuracy as possible.
LSB 5.0 was released on 2015
[1] rpm -q redhat-lsb-desktop -l --requires /usr/bin/fc-cache /usr/bin/fc-list /usr/bin/fc-match atk(x86-64) cairo(x86-64) freetype(x86-64) gdk-pixbuf2(x86-64) glib2(x86-64) gtk2(x86-64) libICE(x86-64) libSM(x86-64) libX11(x86-64) libXext(x86-64) libXft(x86-64) libXi(x86-64) libXrender(x86-64) libXt(x86-64) libXtst(x86-64) libjpeg-turbo(x86-64) libpng(x86-64) libpng12.so.0()(64bit) libxml2(x86-64) mesa-libGL(x86-64) mesa-libGLU(x86-64) pango(x86-64) qt(x86-64) qt-x11(x86-64) redhat-lsb-core(x86-64) = 5.0-2.20231006git4d6a9e05.fc38 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 xdg-utils
[2] /etc/lsb-release.d/desktop-5.0-amd64 /etc/lsb-release.d/desktop-5.0-noarch
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.
yeah it is required by policies , but policies are very outdated and I think the best effort is applicable.
you mean use %bdond macros to conditionalize the whole subpackage ?
For now the goal is bring LSB core and usr/bin/lsb_release to epel9, which will fix many problem, we can add perl packages to epel , spax I even don't know for what is it but seems very old and nobody use it nowadays .
I guess ibxcrypt-compat is only available on epel but not on Centos , that why my test failed ...
This update can be pushed to stable now if the maintainer wishes
@carlwgeorge may I push it to stable ?
@carlwgeorge may I push it to stable ?
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.
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.
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.
sergiomb edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by sergiomb.
This update has been pushed to testing.
please send me PR(s), I don't have more time , so do you prefer not have lsb at all in epel9 ? This package is not maintained since 2011 , more or less, and nobody cares about missing commands , the only thing that is needed is lsb_release
dnf install infocmp No match for argument: infocmp
infocmp doesn't exist in Fedora 38
reading https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/normativerefs.html#STD.SUSV4
The normative references are dated between 1999 and 2009 , for a specification of 2015 , therefore I proppose just the best effort to be compliant
install_initd and remove_initd are available in /usr/lib/lsb/ of redhat-lsb-core
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.
"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 don't agree with you at all, first after I did a lot of effort on make redhat-lsb-5.0 , it's appear yesterday one minimal lsb_release from a fork which is even less compliant and completely buggy .
second redhat-lsb-5.0 try provide all software that Fedora/Redhat have to LSB compliance , and if we miss some few because they already doesn't exist, we provide the core of the packages that LSB wants . Is the only way, we can do, to provide LSB , and wait for LSB 6.0
sergiomb edited this update.
https://pagure.io/fesco/issue/3089
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
https://pagure.io/epel/issue/255
This update can be pushed to stable now if the maintainer wishes
Per https://pagure.io/epel/issue/255#comment-883244, I'm going to unpush this for now.
This update has been unpushed.
sergiomb edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by sergiomb.
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.
AGREED: lsb_release (all implementations) must not report compliance with LSB, because various components are missing from Fedora, so compliance is not possible. (+6, 0, 0)
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.This needs to be patched to report "n/a", which is what the minimal lsb_release package reports for that command.
2 things first , lsb_release is the offender , it is an hijack of this package done by Neal Gompa second
This package is not compliance with LSB, because various components are missing from Fedora or EPEL, so compliance is not possible. Fedora or EPEL explicitly declines add support the missing components from LSB 5.0 or earlier because these components are very outdated and have been removed from the repositories and possibly replaced with new ones. This package tries its best to comply with the LSB. Hoping to be helpful and continue to support the LSB project and software that use it
so lsb_release report this not compliance with LSB, because various components are missing from Fedora, so compliance is not possible.
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 addConflicts: 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.
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.
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.
This update has been pushed to testing.
The conflict with
lsb_release
and the false promise that this implements LSB compliance is troublesome. I don't think this should be pushed (I question ifredhat-lsb
should actually just be retired, it has outlived its usefulness in Fedora as well)Agree with @carlwgeorge and @salimma for points made above
This update has been obsoleted.
sergiomb edited this update.
New build(s):
Removed build(s):
Karma has been reset.
" This needs to be patched to report "n/a", which is what the minimal lsb_release package reports for that command. "
done
now I have a bug in bodhi ,
sergiomb edited this update.
sergiomb edited this update.
New build(s):
Removed build(s):
Karma has been reset.
reported here : https://github.com/fedora-infra/bodhi/issues/5815
sergiomb edited this update.