obsolete

redhat-lsb-5.0-0.9.20231006git8d00acdc.el9

FEDORA-EPEL-2023-336dbb57e0 created by sergiomb a year ago for Fedora EPEL 9
  • 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

  • redhat-lsb now provides lsb_release, in future maybe we can remove the rest of sub-packages since LSB 5.0 is out of date

This update has been submitted for testing by sergiomb.

a year ago

This update's test gating status has been changed to 'ignored'.

a year ago
User Icon carlwgeorge commented & provided feedback a year ago
karma

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
BZ#2088871 Please branch and build redhat-lsb in epel9

This update has been pushed to testing.

a year ago

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.

a year ago

sergiomb edited this update.

New build(s):

  • redhat-lsb-5.0-0.3.20231006git8d00acdc.el9

Removed build(s):

  • redhat-lsb-5.0-0.2.20231006git8d00acdc.el9

Karma has been reset.

a year ago

This update has been submitted for testing by sergiomb.

a year ago
User Icon sergiomb commented & provided feedback a year ago

Fixed

This update has been pushed to testing.

a year ago
User Icon carlwgeorge commented & provided feedback a year ago

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.

User Icon sergiomb commented & provided feedback a year ago

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

User Icon carlwgeorge commented & provided feedback a year ago

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.

User Icon sergiomb commented & provided feedback a year ago

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

a year ago
User Icon sergiomb commented & provided feedback a year ago

@carlwgeorge may I push it to stable ?

User Icon sergiomb commented & provided feedback a year ago

@carlwgeorge may I push it to stable ?

User Icon carlwgeorge commented & provided feedback a year ago
karma

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.

User Icon carlwgeorge commented & provided feedback a year ago

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.

sergiomb edited this update.

New build(s):

  • redhat-lsb-5.0-0.4.20231006git8d00acdc.el9

Removed build(s):

  • redhat-lsb-5.0-0.3.20231006git8d00acdc.el9

Karma has been reset.

a year ago

This update has been submitted for testing by sergiomb.

a year ago

This update has been pushed to testing.

a year ago
User Icon sergiomb commented & provided feedback a year ago

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.

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

User Icon sergiomb commented & provided feedback a year ago

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

User Icon sergiomb commented & provided feedback a year ago

install_initd and remove_initd are available in /usr/lib/lsb/ of redhat-lsb-core

ll /usr/lib/lsb/
total 4
-rwxr-xr-x 1 root root 635 Apr 10  2023 init-functions
lrwxrwxrwx 1 root root  23 Apr 10  2023 install_initd -> ../../../sbin/chkconfig
lrwxrwxrwx 1 root root  23 Apr 10  2023 remove_initd -> ../../../sbin/chkconfig
User Icon carlwgeorge commented & provided feedback a year ago

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.

User Icon sergiomb commented & provided feedback a year ago

"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.

a year ago

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.

a year ago

This update can be pushed to stable now if the maintainer wishes

a year ago
User Icon salimma provided feedback a year ago
karma
BZ#2088871 Please branch and build redhat-lsb in epel9
User Icon carlwgeorge commented & provided feedback a year ago

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):

  • redhat-lsb-5.0-0.8.20231006git8d00acdc.el9

Removed build(s):

  • redhat-lsb-5.0-0.4.20231006git8d00acdc.el9

Karma has been reset.

12 months ago

This update has been submitted for testing by sergiomb.

12 months ago
User Icon carlwgeorge commented & provided feedback 12 months ago
karma

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.

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.

User Icon sergiomb commented & provided feedback 12 months ago

2 things first , lsb_release is the offender , it is an hijack of this package done by Neal Gompa second

I added the following description to package and all sub-packages:

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

redhat-lsb (main package) now provides lsb_release, in future maybe we can remove the rest of sub-packages since LSB 5.0 is out of date

so lsb_release report this not compliance with LSB, because various components are missing from Fedora, so compliance is not possible.

User Icon carlwgeorge commented & provided feedback 12 months ago

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.

User Icon carlwgeorge commented & provided feedback 12 months ago

I'll also reiterate the decision from the EPEL Steering Committee:

Once this has been completed, the EPEL Steering Committee will re-discuss this issue to decide if redhat-lsb is a good fit for EPEL or not.

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.

12 months ago
User Icon salimma commented & provided feedback 12 months ago
karma

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 if redhat-lsb should actually just be retired, it has outlived its usefulness in Fedora as well)

BZ#2088871 Please branch and build redhat-lsb in epel9
User Icon jrichardson commented & provided feedback 12 months ago

Agree with @carlwgeorge and @salimma for points made above

BZ#2088871 Please branch and build redhat-lsb in epel9
karma
BZ#2088871 Please branch and build redhat-lsb in epel9

This update has been obsoleted.

12 months ago

sergiomb edited this update.

New build(s):

  • redhat-lsb-5.0-0.13.20231006git8d00acdc.el9

Removed build(s):

  • redhat-lsb-5.0-0.8.20231006git8d00acdc.el9

Karma has been reset.

3 months ago
User Icon sergiomb commented & provided feedback 3 months ago

" 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.

3 months ago

sergiomb edited this update.

New build(s):

  • redhat-lsb-5.0-0.9.20231006git8d00acdc.el9

Removed build(s):

  • redhat-lsb-5.0-0.13.20231006git8d00acdc.el9

Karma has been reset.

3 months ago

sergiomb edited this update.

3 months ago

Please login to add feedback.

Metadata
Type
newpackage
Severity
medium
Karma
0
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
3
Stable by Time
disabled
Thresholds
Minimum Karma
+1
Minimum Testing
7 days
Dates
submitted
a year ago
modified
3 months ago
BZ#2088871 Please branch and build redhat-lsb in epel9
0
0

Automated Test Results