RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2012924 - redhat-lsb packages not present in CentOS Stream 9 production compose
Summary: redhat-lsb packages not present in CentOS Stream 9 production compose
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: redhat-lsb
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
: 2036858 (view as bug list)
Depends On:
Blocks: 1875977
TreeView+ depends on / blocked
 
Reported: 2021-10-11 15:52 UTC by Alfredo Moralejo
Modified: 2023-10-06 16:39 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-07-12 20:04:49 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-99456 0 None None None 2021-10-11 20:07:23 UTC
Red Hat Knowledge Base (Solution) 6969134 0 None None None 2022-07-23 22:50:04 UTC
Red Hat Knowledge Base (Solution) 6973382 0 None None None 2022-08-26 18:51:05 UTC

Internal Links: 2118596

Description Alfredo Moralejo 2021-10-11 15:52:55 UTC
Description of problem:

As latest compose:

date = 20211006
id = CentOS-Stream-9-20211006.2

There is on redhat-lsb-core (or any other redhat-lsb subpackage) available.

This package has been used to make sure we have all packages installed to have a LSB core system.

May this package be included in CS9 composes asap?. By navigating bz, i haven't found if there is any actual issue with redhat-lsb or if there is any plan to remove it from rhel (hopefully not).

Comment 4 Brian Stinson 2021-10-19 15:47:54 UTC
Folks should plan to require all individual components that are needed. We do not plan to include the redhat-lsb packages.

Comment 5 Alex Iribarren 2021-11-08 13:44:43 UTC
So what provides lsb_release now?

Comment 6 Akshay Nahar 2021-11-17 11:07:43 UTC
Hello Team,

Will redhat-lsb packages be part of RHEL 9 GA version ?
If not what will the alternative for lsb_release utility.

Regards,
Akshay

Comment 7 Brian Stinson 2021-11-17 14:16:49 UTC
There are no plans to ship the lsb_release utility in RHEL 9 GA. 

Many projects are reading /etc/os-release, /etc/redhat-release, or /etc/system-release to gather the information they need.

Comment 8 Neal Gompa 2021-11-19 14:05:49 UTC
(In reply to Brian Stinson from comment #7)
> There are no plans to ship the lsb_release utility in RHEL 9 GA. 
> 
> Many projects are reading /etc/os-release, /etc/redhat-release, or
> /etc/system-release to gather the information they need.

Please ensure the recommendation is to read /etc/os-release rather than any of the other files when guidance is released for porting to RHEL 9. It's the only file of those three with a standardized format.

Comment 10 Gerwin Krist 2022-04-06 13:30:49 UTC
We are in the process of testing RHEL 9 for deployment. This one hit us by a little surprise as we were relying on: /usr/bin/lsb_release -s -r 

We use https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/pdf/considerations_in_adopting_rhel_9/red_hat_enterprise_linux-9-beta-considerations_in_adopting_rhel_9-en-us.pdf as baseline to find possible problems and there is no talking about lsb-core being deprecated/removed. IMHO it should be noted there.

Comment 11 Carsten Jacobi 2022-05-18 08:47:55 UTC
+1 also from my side. I just started to evaluate RHEL9 for our needs and am blocked right from the start when I want to make my first custom tools and can't because 'lsb_release' is missing. I also want to remind you how you described the tool package yourself in the past:

Description : The Linux Standard Base (LSB) Core module support provides the
            : fundamental system interfaces, libraries, and runtime environment
            : upon which all conforming applications and libraries depend.

Of course, there may be other ways to browse through /etc and try to find various config files there which will eventually tell you on which distribution and which level you are, but with 'lsb_release' there was some common tool that also worked for example on Debian, Ubuntu, SuSE … and maybe even more distributions.
Now, dropping that tool you deviate from that commonality. IMHO that's a step backward.

(In reply to Gerwin Krist from comment #10)
> We are in the process of testing RHEL 9 for deployment. This one hit us by a
> little surprise as we were relying on: /usr/bin/lsb_release -s -r 
> 
> We use
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-
> beta/pdf/considerations_in_adopting_rhel_9/red_hat_enterprise_linux-9-beta-
> considerations_in_adopting_rhel_9-en-us.pdf as baseline to find possible
> problems and there is no talking about lsb-core being deprecated/removed.
> IMHO it should be noted there.

Comment 12 Yehuda Katz 2022-06-16 21:12:32 UTC
I know this already says WONTFIX, but we also have so many tools that rely on lsb_release to get standard information about systems. Please bring it back.

Comment 14 Josh Boyer 2022-06-16 21:19:44 UTC
We encourage customers having issues with the lack of this package to file support cases and outline the applications that require the redhat-lsb package.

Comment 17 Anton 2022-07-04 14:34:05 UTC
Package `epson-inkjet-printer-escpr-1.7.19-1lsb3.2.x86_64` (drivers for Epson printers) requires `lsb`. Does anyone have an idea how to make it work (except for writing to Epson's support, that's a last resort option)?

Comment 22 Anton 2022-07-17 20:35:33 UTC
During my spare time, I've actually built `redhat-lsb` package myself in 2 hours using `rpmbuild ---rebuild` and Fedora 35 source package (`redhat-lsb-4.1-55.fc35.src.rpm`). So, there should be absolutely no excuse why you cannot do the same on a _paid_ job.

Thanks, RedHat.

P.S. I can even share a YouTube livestream link to prove that it's really not so complicated.

P.P.S. And yes, my printer drivers installed just fine after doing that.

P.P.P.S. Here's the output of `uname -a`, `cat /etc/redhat-release` and `lsb_release -a`:

```
$ uname -a
Linux anton-RHEL 5.14.0-70.17.1.el9_0.x86_64 #1 SMP PREEMPT Tue Jun 14 11:32:10 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
```

```
$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.0 (Plow)
```

```
$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch:trialuse-4.1-amd64:trialuse-4.1-noarch
Distributor ID:	RedHatEnterprise
Description:	Red Hat Enterprise Linux release 9.0 (Plow)
Release:	9.0
Codename:	Plow
```

P.P.P.P.S. You can contact me via anton2920, if you need help with doing it yourself, since RedHat doesn't seem to care.

Comment 24 Karl Hastings 2022-08-08 04:50:11 UTC
*** Bug 2036858 has been marked as a duplicate of this bug. ***

Comment 29 Michael Huang 2022-08-23 21:28:22 UTC
Any chance to bring the redhat-lsb packages back? We have a software that depends on it too. It will force us to port it to systemd in order to make it run on RHEL9, which is both time-consuming and cost-consuming. 

From Anton's post above, it looks like not that hard for RedHat to bring it back, but it will save 3rd-party ISVs like us a lot of resource, good for RedHat customers too. Thanks

Comment 30 Neal Gompa 2022-08-24 01:41:20 UTC
(In reply to Michael Huang from comment #29)
> Any chance to bring the redhat-lsb packages back? We have a software that
> depends on it too. It will force us to port it to systemd in order to make
> it run on RHEL9, which is both time-consuming and cost-consuming. 
> 

Porting to systemd units and such is something you should be doing anyway. All supported versions of RHEL use systemd and there are significant benefits in doing so.

> From Anton's post above, it looks like not that hard for RedHat to bring it
> back, but it will save 3rd-party ISVs like us a lot of resource, good for
> RedHat customers too. Thanks

Nothing stops this package from being introduced into EPEL. https://docs.fedoraproject.org/en-US/epel/epel-package-request/

Comment 32 Carl George 🤠 2022-08-24 02:46:38 UTC
If the Fedora redhat-lsb maintainer wants to branch that package for epel9, they can.  However, I strongly advise against it.  It pulls in an awful lot of dependencies just to be able to run the lsb_release command.  Instead, I'd recommend switching to a modern alternative such as distro (part of the python3-distro package, already shipped in RHEL8 and RHEL9).  It has optional json output that can be parsed programmatically.

Comment 33 Kyle Walker 2022-08-26 18:51:05 UTC
For those seeking additional information regarding this omission, the following article has been published:

    Why is the redhat-lsb package not available in Red Hat Enterprise Linux 9? - Red Hat Customer Portal
    https://access.redhat.com/solutions/6973382

Please reach out to Red Hat support for questions or additional guidance regarding this topic.

    How do I open and manage a support case on the Customer Portal? - Red Hat Customer Portal
    https://access.redhat.com/articles/38363

Comment 34 Sergio Basto 2023-02-05 16:25:05 UTC
please follow this bug report https://bugzilla.redhat.com/show_bug.cgi?id=2118596 , as this is Red Hat Enterprise Linux 9 bug and we maybe will fix it on EPEL 9

Comment 35 axmonti 2023-06-06 06:40:02 UTC
(In reply to Anton from comment #17)
> Package `epson-inkjet-printer-escpr-1.7.19-1lsb3.2.x86_64` (drivers for
> Epson printers) requires `lsb`. Does anyone have an idea how to make it work
> (except for writing to Epson's support, that's a last resort option)?

This is a bit late, but just in case anyone is trying to install Epson Drivers on RHEL without lsb, I extracted the README from the Epson RPM and there are instructions on how to build from source without requiring lsb. The relevant section of the README is included here for convenience:

-------------------------------------------------------------------------------
6  How to build in non-LSB distribution
-------------------------------------------------------------------------------
6.1  For Redhat based distributions
	6.1.1  Uncompress the src.rpm file
	   $ rpm2cpio epson-inkjet-printer-escpr-1.7.xx-1lsb3.2.src.rpm | cpio -id
	   $ tar zxvf epson-inkjet-printer-escpr-1.7.xx-1lsb3.2.tar.gz

	6.1.2  Configure and Create source tarball
	   $ cd epson-inkjet-printer-escpr-1.7.xx
	   $ ./bootstrap && ./configure --prefix=/usr && make dist

	6.1.3  Create the directory for RPM packages
	   $ mkdir -p ~/rpmbuild/SOURCES
	   $ mkdir -p ~/rpmbuild/SPECS
	   $ mkdir -p ~/rpmbuild/BUILD
	   $ mkdir -p ~/rpmbuild/RPMS
	   $ mkdir -p ~/rpmbuild/SRPMS
	   
	   You can specify the another directory in ~/.rpmmacros
	   
	6.1.4  Copy the source tarball and the spec file to the directory
	   $ cp epson-inkjet-printer-escpr-1.7.xx.tar.gz ~/rpmbuild/SOURCES/.
	   $ cp epson-inkjet-printer-escpr.spec ~/rpmbuild/SPECS

	6.1.5  Create RPM package
	   $ cd ~/rpmbuild/SPECS
	   $ rpmbuild -ba --clean epson-inkjet-printer-escpr.spec
-------------------------------------------------------------------------------

Then install the newly created RPM from the RPMS directory with: sudo rpm -i epson-inkjet-printer-escpr-1.7.26-1.x86_64.rpm
Substitute your version and platform for 1.7.26-1 and x86_64, respectively.

Note that you have to download the "src" RPM from Epson as opposed the platform-specific file (it's one of the download options in the generic driver list). You may also have to run "automake --add-missing" before bootstrap, plus you may need to add "%global debug_package %{nil}" before the "%prep" section in the epson spec file. I didn't need to SUDO  or run as root.

The entire process took 10 minutes and my Epson printer works perfectly; hope this helps.

Comment 36 Japheth Cleaver 2023-10-05 07:12:25 UTC
(In reply to Carl George 🤠 from comment #32)
> If the Fedora redhat-lsb maintainer wants to branch that package for epel9,
> they can.  However, I strongly advise against it.  It pulls in an awful lot
> of dependencies just to be able to run the lsb_release command.  Instead,
> I'd recommend switching to a modern alternative such as distro (part of the
> python3-distro package, already shipped in RHEL8 and RHEL9).  It has
> optional json output that can be parsed programmatically.


The lsb_release command clearly ALREADY contemplates being executed (and thus available) on non-LSB-compliant systems. At the very least, this command should be available. Call it a redhat-lsb-core-compat RPM or something, or redhat-lsb-core-notreally, for all that it matters. Or please just package the script separately as 'lsb_release'. Either way, this was a miss.

From man lsb_release: 

    $ ./lsb_release --all
       LSB Version:    core-2.0-ia64:core-2.0-noarch:graphics-2.0-ia64:graphics-2.0-noarch
       Distributor ID: MyDistrib
       Description:    I enjoy using my distrib
       Release:        1.0RC4
       Codename:       TryIt

       $ ./lsb_release -a -s
       1.0 MyDistrib "I enjoy using my distrib" 1.0RC4 TryIt

       If the "/etc/lsb-release" file is absent (indicating this is not an LSB compliant distribution), the result will be:

       $ ./lsb_release -a
       LSB Version:    n/a
       Distributor ID: MyDistrib
       Description:    My Linux Distrib release 1.0RC4 (TryIt)
       Release:        1.0RC4
       Codename:       TryIt

Comment 37 Carl George 🤠 2023-10-05 18:37:13 UTC
> At the very least, this command should be available. Call it a redhat-lsb-core-compat RPM or something, or redhat-lsb-core-notreally, for all that it matters. Or please just package the script separately as 'lsb_release'.

Nothing is stopping you from creating and maintaining an open source project named lsb-release (or lsb-core, or lsb-core-compat, or whatever) that provides the lsb_release command, packaging it for Fedora, and then branching it for EPEL 9.

If you don't want to maintain a new open source project, then switch to using the existing, maintained, and packaged python-distro tool.

Comment 38 Sergio Basto 2023-10-06 16:39:53 UTC
BTW, redhat-lsb-5.0 is arriving to epel 9. 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-336dbb57e0

Any feedback or help is welcome .


Note You need to log in before you can comment on or make changes to this bug.