I am seeking guidance from FESCo on the redhat-lsb package. This package has been around a long time. I'm not going to recap the entire history, but for context I would like to highlight a few key events. I am also going to describe the current shortcomings.
While this package was in the testing repo for EPEL 9, I noticed that multiple subpackages were not installable. I provided negative karma on the update to inform the maintainer (@sergiomb) and prevent the time-based automatic push to stable. Sérgio first proposed a fix of conditionally disabling the dependencies that were missing. Later he adjusted this to make them weak dependencies (Recommends). Neither of these are appropriate. The entire point of the LSB standard is to guarantee that certain commands and libraries are available. From the package's own description:
Recommends
The lsb package provides utilities, libraries etc. needed for LSB Compliant Applications. It also contains requirements that will ensure that all components required by the LSB are installed on the system.
If a package exists that claims to implement the LSB specification, then it needs to have the same dependencies in both Fedora and EPEL. Furthermore, these dependencies must be correct. Anything less is setting up our users for missed expectations. From a quick check of the specification of the core module, at least three required commands are not required by the package. I have not fully reviewed the other LSB modules, but based on what I've seen so far I suspect there are further missing or incorrect dependencies. If the package is allowed to stay in the distribution, I think an in depth audit should be conducted to correct these flaws. So far Sérgio has refused to do the work to add the missing dependencies to EPEL 9, instead arguing that because the LSB specification itself is outdated, that an incomplete "best effort" implementation in the package is good enough. I disagree, and believe that if the specification cannot be met then the corresponding package should be retired.
As highlighted in the key events section above, the upstream for this package has not been updated for over eight years. This was a driving factor in redhat-lsb being removed from RHEL 9. Fedora's Policy for Orphan and Retired Packages states that packages whose upstream do not exist anymore should be retired. From a package maintainer perspective, being unmaintained is effectively the same as not existing (although perhaps this should be clarified explicitly in that policy). It is also not clear from the spec file what upstream is being used. Source0 is a tarball with no URL, with no explaination of how the tarball was generated.
Sérgio correctly identified that the most important part of this package is providing the lsb_release command. We have both observed multiple users state that compliance with the LSB is not actually what they desire. The most common scenario is a third party package requiring the lsb_release command. In general we should encourage these third parties to port to reading /etc/os-release directly, or using a currently maintained tool like distro. However, until these third parties (who are notoriously slow to modernize) make these changes, there will still be a need for the lsb_release command. There is a minimal alternative which is explicitly not a full implementation of the LSB. Its sole purpose is to provide the lsb_release command. This was recently packaged into Fedora and EPEL.
lsb_release
/etc/os-release
Due to the upstream state of LSB, the condition of the redhat-lsb package, and the presence of the lsb_release package, I think the best way to proceed would be to retire the redhat-lsb package, effectively making the lsb_release package the standard for Fedora.
I brought up this situation at the most recent EPEL Steering Commitee meeting, specifically in the context of using weak dependencies instead of making the necessary dependencies available in EPEL. We agreed that this was not appropriate, and in its current state the package should not be shipped in EPEL 9. During this meeting it was also suggested to bring this issue to FESCo.
The retirement policy states that retirement is only allowed prior to final freeze. F39 has already passed that date, but has not yet released. If FESCo agrees that redhat-lsb should be retired, it may be worth considering making an exception to retire it to avoid maintaining it for the lifetime of F39.
these sources https://pagure.io/redhat-lsb are a fork of https://github.com/LinuxStandardBase/lsb-samples/commits/ after I added redhat-lsb-4.1-1.tar.bz2 as described README.md
lsb_release from this location give a better results than lsb_release from thkukuk repo
for example in thkukuk repo all names are hard coded https://github.com/thkukuk/lsb-release_os-release/blob/master/lsb_release#L196
The lsb fedora package has not been maintained since 2015 or even more, as stated I adopted it in 2022-06-21, I fix it, an now I update it to 5.0, I did a research of the state of lsb on other distros, I try organized all patches and fixes over internet and I do not include thkukuk patches because they aren't good in my point of view .
And of course, I think we should keep lsb-core in Fedora , I have a very different vision of carlwgeorge about redhat-lsb-5.0, the package should try provide all software that Fedora/Redhat have to LSB compliance but we shouldn't add or keep old software just to be LSB compliance. If we don't have ncurses <= 4 or libcrypt.so.1 or qt4 we don't provide it , but we provide all other software .
At least provide lsb_release from redhat-lsb-4.1-1 or redhat-lsb-5.0 which is the same of https://github.com/LinuxStandardBase/lsb-samples/ more small fixes , that I was planning upstream it. [1]
[1]
* 5e07d66 2023-10-06 05:20 Sérgio M. Basto Fix fsf address * 56d1763 2017-08-15 11:38 Thorsten Kukuk Update COPYING file * f23800e 2017-08-15 11:37 Thorsten Kukuk Manual pages are in /usr/share/man * 3c5639b 2017-08-15 11:21 Thorsten Kukuk Document /etc/os-release usage of lsb_release * 171ebd2 2023-04-25 06:41 Sérgio M. Basto lsb_release_make_man_page_reproducible, from archlinux I think * 0c1e0f0 2023-04-23 08:59 Sérgio M. Basto lsb-release-2.0-disable-etc-lsb-release.patch * ba086f9 2023-04-10 12:39 Sérgio M. Basto Force +x
but why we not use the current lsb_release of redhat-lsb package ?
I look at Fedora software and try do my best , I see many things unmaintained , and try try fix , with one priority order , lsb was one of them , but after I fix the thing you came up with better solution, why you didn't fix this package 8 year ago ? , why suddenly you remember that remove lsb is the best option ? , lsb is on rhel 8 . Maybe I can send to you list list of things that I'm planning todo , to Neal Gompa fix it
the bugs on thkukuk release :
lsb_release -c Codename: n/a lsb_release LSB Version: n/a lsb-release -s n/a
also is add one lsb-release with hyphen and is not needed , is a symbol link that just brings more confusion , the command is lsb_release
the version name is hard coded https://github.com/thkukuk/lsb-release_os-release/blob/master/lsb_release#L196 , so I suppose this won't work on centos clones like rocky linux or scientific linux
while lsb_release from redhat-lsb:
lsb_release LSB Version: :core-5.0-amd64:core-5.0-noarch lsb_release -c ThirtyEight lsb_release -s :core-5.0-amd64:core-5.0-noarch
Firstly, Fedora isn't LSB compliant. Neither is RHEL. The output from lsb_release(1) from lsb_release is correct in saying n/a because we do not have any LSB compliance.
lsb_release(1)
n/a
Secondly, people should already not be using lsb_release(1) in the first place. But if there's legitimate missing output, patches are welcome upstream to resolve that.
Thirdly, fixing it for handling distributions generically was not hard: https://src.fedoraproject.org/rpms/lsb_release/c/06c48785652d59e6e1de656f6c550b12e8716773
Proposal: FESCo requests that redhat-lsb be retired from F39+ per the issues brought up by @carlwgeorge and the pending introduction of an alternate lsb_release package that provides the compatibility tool using os-release(5) data.
redhat-lsb
os-release(5)
I'm fast-tracking this given the timeframe between now and GA.
Metadata Update from @ngompa: - Issue set to the milestone: Fedora Linux 39 - Issue tagged with: fast track
+1 for the proposal
+1 as well
Point 1 - why we not use the current lsb_release of redhat-lsb package ?
Point 2 - Fedora isn't LSB 100% compliant but have some LSB compliance and just is not fully complaint because Linux foundation haven't update the specifications since 2015 but IMO we should keep some LSB functions .
Point 3 - I do not subscribe "We have both observed multiple users state that compliance with the LSB is not actually what desired " , I have both observed multiple users state that we haven't LSB at all in EL 9 and that was my motivation to do LSB 5.0
-1 for the propose
So, if I understand this correctly, we've had /etc/os-release and Python's distro packages for a long time and those are what should primarily be used. There's a lingering, minimal lsb_release that can be used to return a small subset of data if needed.
I'm +1 for retiring redhat-lsb.
Because it's wrong. It says things that aren't true and itself doesn't work right.
No. It's better to not claim any compliance than partial compliance, especially since the LSB tooling makes no meaningful way to describe it.
To the best of my knowledge, I am the only person who has ever officially asked for LSB 5.0 compliance, and that was in 2016. Since then, the Linux Foundation shut down the LSB project and everything rotted. In 2016, it was possible. In 2023, it is not.
That said, I am aware of a lot of third-party software that requires lsb_release(1) to run properly, especially old configuration management software. We now have an implementation that satisfies this.
+1
It's time for the LSB stuff to go.
The change seems OK, but I'm not convinced about fast tracking it. The release is already behind schedule. Can someone elaborate more on the downsides of having it in Fedora 39?
We'd be stuck with a broken package for the entire life for Fedora 39. This is the fairly basic answer here. Dropping the package from the repositories now is our only option and shouldn't affect the schedule any further, since it's not preloaded on any media.
@ngompa Is the Fedora 39 package more broken than the one in Fedora 38?
No, but keeping it around means we have to deal with its existence for another 13~15 months.
Point 1 - why we not use the current lsb_release of redhat-lsb package ? Because it's wrong. It says things that aren't true and itself doesn't work right.
lsb_release from redhat-lsb package is not wrong , from where you got that idea ? , LSB Version: shows what is in /etc/lsb-release.d/
good , one less bug, did you test the commit ?
We'd be stuck with a broken package for the entire life for Fedora 39
the package was broken since 2016 , now is not broken , see for example https://bugzilla.redhat.com/show_bug.cgi?id=1298936 and this one https://bugzilla.redhat.com/show_bug.cgi?id=1625584
linux-foundatio seems that is alive https://sdtimes.com/open-source/linux-foundation-launches-community-specification-for-creating-standards-and-specifications/
final note, I tried to announce and spread the change honestly, after some work, I didn't expect that from one day to the next the decision would be made to use a parallel lsb_release and that left me upset, I consider it a hijack
bye
I understand the desire to avoid maintaining this package longer, but I don't think this warrants a fast track so late in the release process. I'm -1 on this for now unless there is some new information that is shared.
It feels to me like this change needs to go through the full change proposal process.
Point 1 - why we not use the current lsb_release of redhat-lsb package ? Because it's wrong. It says things that aren't true and itself doesn't work right. lsb_release from redhat-lsb package is not wrong , from where you got that idea ? , LSB Version: shows what is in /etc/lsb-release.d/
It's wrong because we cannot conform to the LSB spec.
Thirdly, fixing it for handling distributions generically was not hard: https://src.fedoraproject.org/rpms/lsb_release/c/06c48785652d59e6e1de656f6c550b12e8716773 good , one less bug, did you test the commit ? We'd be stuck with a broken package for the entire life for Fedora 39 the package was broken since 2016 , now is not broken , see for example https://bugzilla.redhat.com/show_bug.cgi?id=1298936 and this one https://bugzilla.redhat.com/show_bug.cgi?id=1625584
These bug reports (and others) are further evidence that we shouldn't have this package anymore. We cannot comply with the spec and partial compliance helps nobody at all because it's all a lie and programs that actually expect conformance (if any still exist) will be broken in difficult-to-detect ways.
I didn't say LF is dead. I said LSB is.
This happened because it came up in the EPEL meeting last week (@carlwgeorge filed a ticket about it as epel#255).
I recommended it be forwarded to FESCo because of the breadth of issues around this.
the package was broken since 2016 , now is not broken
Unfortunately it is still very much broken. redhat-lsb is missing many of the things that LSB 5.0 requires. Some of these requirements are not even possible to fulfill on Fedora. It's a big specification, and I haven't reviewed all of it, but every time I look I find more problems. Some examples:
/usr/bin/infocmp
/usr/bin/tic
/usr/bin/tput
/usr/bin/python
CGI::Apache
libasound.so.2
libfontconfig.so.1
libtiff.so.5
libxcb.so.1
final note, I tried to announce and spread the change honestly,
I apologize for not seeing your previous emails to the mailing list. I first became aware of your efforts to update the package when I noticed the proposed EPEL 9 update with multiple packages that failed to install. Only then did I search on the mailing list archive to understand more of the history. I wish I had noticed those emails earlier so we could have discussed the flaws in both the package and in the standard itself before you spend time working on it. However, allowing that time spent to factor into an evaluation of retiring the package is an example of sunk cost fallacy.
after some work, I didn't expect that from one day to the next the decision would be made to use a parallel lsb_release and that left me upset, I consider it a hijack
No one is "hijacking" you. We just care about the quality of Fedora. Shipping a broken package, with missing requirements (some of which are not fixable), is bad for Fedora. Neal packaged the minimal lsb_release to give users an alternative way to get that command without dealing with the full LSB expectations, which is the predominate use case.
See my previous comment for just a few examples of how the current package is broken. That's why I would prefer to retire it in F39. That said, I understand that it is quite late in the schedule, so if FESCo would prefer to only retire this package from Rawhide and leave it in F39 I would understand.
How would the change process work when the maintainer of the package in question is against making the change? I'll also note that the retirement policy does not mandate a change proposal, and the change policy makes no mention of package retirements.
How would the change process work when the maintainer of the package in question is against making the change?
This is the reason I suggested the change process. It seems like there is a disagreement and having a coummunity-wide discussion might help.
I'll also note that the retirement policy does not mandate a change proposal, and the change policy makes no mention of package retirements.
Right, but it doesn't say you need to create a FESCO ticket either. Was your goal in filing the ticket to resolve the disagreement or was your goal just to try to get it retired in f39+ instead of f40+?
Also, this is not only a retirement proposal. It's a proposal to retire and replace with something else. It's common to have change proposals for scenarios like this.
lsb_release is going into the repositories regardless. It's already set up to conflict with redhat-lsb-core and exists as an alternative implementation. From the perspective of this ticket, it does not matter beyond the fact it exists.
redhat-lsb-core
As stated in my original post ("I think the best way to proceed would be to retire the redhat-lsb package"), the goal is to get the package retired in general. The maintainer disagrees with that action despite the broken and misleading state of the package and the defunct upstream. Whether that is retirement from F39+ or F40+ doesn't really make that much difference to me. I brought up retiring it in F39 as merely something worth considering ("it may be worth considering making an exception to retire it to avoid maintaining it for the lifetime of F39") because I think it would be quite low risk.
I know I mentioned the minimal lsb_release in the original post, but Neal is right that it is effectively orthogonal. There is no obsoletes directive, just a conflicts. lsb_release doesn't provide any redhat-lsb names either. It's a compatibility alternative for those users that are unfortunate enough to be running software that has a hard requirement on /usr/bin/lsb_release. Everything else about redhat-lsb is exactly the same even if lsb_release didn't exist.
/usr/bin/lsb_release
Unless @tstellar changes his -1, the fast track is invalidated and we're going to discuss this at the next FESCo meeting on Thursday.
-1
Metadata Update from @ngompa: - Issue tagged with: meeting
Metadata Update from @ngompa: - Issue untagged with: fast track
We discussed this ticket in our meeting today. No decisions were made, so the in ticket voting process will continue as usual.
Metadata Update from @tstellar: - Issue untagged with: meeting
Metadata Update from @ngompa: - Issue set to the milestone: Fedora Linux 40 (was: Fedora Linux 39)
I see two sides to the question: - on the technical level, LSB is mostly obsolete and it looks like lsb_release would be a reasonable minimal replacement for redhat-lsb. - on the social and procedural level, FESCo shouldn't override the maintainer, except when a package is clearly harmful or duplicate or otherwise a mistake. Even if redhat-lsb does not function as people would like, it has an active maintainer and it's up to the maintainer to retire the package or not and how to handle missing dependencies.
If EPEL Steering Committee wants to reject the package from EPEL, that's up to them.
-1 to the proposal.
(I think the package probably should be retired, I just don't think it's a decision for FESCo to make.)
(Also, I think that Fast Track is not at all appropriate for such a ticket. It's good that @tstellar axed the request.)
Since this received another -1 vote, does it need to be discussed again in a meeting or should we count the votes now that it has been a week?
The voting policy requires that proposals with at least one -1 must be discussed at a meeting.
Metadata Update from @sgallagh: - Issue tagged with: meeting
We already discussed this during last week's meeting and sent it back to in-ticket voting, though ...
In general, I would absolutely agree with you. The LSB is kind of an edge-case, though. It is intended to be representative of the distribution as a whole, which is FESCo's responsibility. This role has been mostly overtaken by os-release over time, but there are still services out there that expect valid data to be provided here.
os-release
Whether or not the package gets retired, I think FESCo really should be involved in determining what information is provided by the lsb_release tool.
I'm open to contributing or adjusting lsb_release as needed as long as we aren't claiming LSB conformance when we can't really do that.
I was reading through the voting process again, and it looks like we are supposed to wait the full week before adding the meeting tag, so maybe we did that prematurely in this case.
FTR, this is output of lsb_release -a on rawhide:
lsb_release -a
LSB Version: n/a Distributor ID: Fedora Description: Fedora Linux 40 (Rawhide Prerelease) Release: 40 Codename: n/a
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 Distributor ID: Fedora Description: Fedora release 40 (Rawhide) Release: 40 Codename: Rawhide
"Right" is in the eye of the beholder. There clearly is a disagreement as to which output is better.
The big difference between the two packages is that redhat-lsb-* pulls in various other packages as dependencies. Do we know whether our users actually use redhat-lsb-* to install those dependencies, or do they mostly install it to have /bin/lsb_release available? lsb-release.rpm pulls in 117 MB of dependencies, while lsb_release.rpm is only 20KB and doesn't pull anything except some standard shell utilities. If we just care about having /bin/lsb_release, then lsb_release.rpm seems a better approach.
redhat-lsb-*
/bin/lsb_release
lsb-release.rpm
lsb_release.rpm
We already discussed this during last week's meeting and sent it back to in-ticket voting, though ... I was reading through the voting process again, and it looks like we are supposed to wait the full week before adding the meeting tag, so maybe we did that prematurely in this case.
The voting rules are never going to cover every little possibility in detail. I think it's fine if the chair just decides to do something reasonable here.
Do we know whether our users actually use redhat-lsb-* to install those dependencies, or do they mostly install it to have /bin/lsb_release available?
Examples of people asking specifically for /usr/bin/lsb_release:
It's not a disagreement about the output being better or worse. The output of redhat-lsb-core 5.0 in Rawhide is false according to its own criteria.
root@f40-container:~# rpm -qf /usr/bin/lsb_release redhat-lsb-core-5.0-0.4.20231006git8d00acdc.fc40.x86_64 root@f40-container:~# lsb_release --help | grep -A1 -- -version -v, --version Display the version of the LSB specification against which the distribution is compliant. root@f40-container:~# lsb_release -v LSB Version: :core-5.0-amd64:core-5.0-noarch
This appears to be a regression from redhat-lsb-core 4.1 in Fedora 39, where that field is blank.
root@f39-container:~# rpm -qf /usr/bin/lsb_release redhat-lsb-core-4.1-62.fc39.x86_64 root@f39-container:~# lsb_release -v LSB Version:
The newly packaged lsb_release instead outputs n/a.
root@f40-container:~# rpm -qf /usr/bin/lsb_release lsb_release-3.2-2.fc40.noarch root@f40-container:~# lsb_release -v LSB Version: n/a
We've already established earlier in this issue that Fedora is not LSB compliant. redhat-lsb incorrectly informs users that their system is compliant with LSB 5.0.
@sergiomb This is going to be discussed again today at 17:00 UTC. FESCo would like you to attend to give your view in #fedora-meeting-2 on irc.libera.chat.
#fedora-meeting-2
@carlwgeorge This is going to be discussed again today at 17:00 UTC. FESCo would like you to attend to give your view in #fedora-meeting-2 on irc.libera.chat.
This was discussed during the meeting last week: 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) AGREED: Fedora explicitly declines to support the LSB 5.0 or earlier. Packagers will remove any information that implies otherwise. No implementation of an LSB package may expressly state or offer compliance for any LSB module that Fedora does not or cannot comply with. (+6, 0, 0)
Those decisions should have been reported here.
Do we want to do something else here? I'll add it to today's agenda.
Metadata Update from @ngompa: - Issue untagged with: meeting
Metadata Update from @zbyszek: - Issue tagged with: meeting
It's been three weeks (one week there was no meeting because of Thanksgiving, and once we didn't have quorum), and no comments have been made. It seems that everything is clear now, so let's close this. If follow-up is needed, please reopen the ticket or open a new one.
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: meeting
FYI , I added to summary of the package (redhat-lsb)
This package is not compliance with LSB, because various components are missing from Fedora, so compliance is not possible. Fedora explicitly declines add support the missing components of LSB 5.0 or earlier because they are completely obsolete.
https://src.fedoraproject.org/rpms/redhat-lsb/c/f3022a48649a0c96f90eb54f7e5786ad3525ce77?branch=rawhide https://src.fedoraproject.org/rpms/redhat-lsb/c/71cf4513374be8ebd51d2786db564d3827cc1a70?branch=rawhide
Log in to comment on this ticket.