Bug 2012924

Folks should plan to require all individual components that are needed. We do not plan to include the redhat-lsb packages.

So what provides lsb_release now?

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

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.

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

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.

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

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.

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.

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

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.

*** Bug 2036858 has been marked as a duplicate of this bug. ***

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

(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/

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.

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

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

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

(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

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

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 .