fesco

#2911 Review removal of ncurses-compat-libs
Closed: Accepted by zbyszek. Opened by labbott.

Closed: Accepted
Reopen Issue

Commit https://src.fedoraproject.org/rpms/ncurses/c/e9317e9 removed support for ncurses-compat-libs (i.e. ncurses5). This broke among other things arm-none-eab-gdb from the gcc toolchains at https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

This toolchain was released in February 2022

$ ./gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin/arm-none-eabi-gdb
./gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin/arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

My older toolchain (released sometime back in 2020)

$ arm-none-eabi-gdb
arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

I expect that further toolchain releases will also continue to be broken unless they decide to compile with ncurses6 which seems unlikely.

I'm not the only person to report this issue https://www.reddit.com/r/Fedora/comments/ygl7zy/can_we_bring_back_ncursescompatlibs_in_fedora_37/
https://bugzilla.redhat.com/show_bug.cgi?id=2129865# was a previous bug I didn't find that cites AOSP as failing to run.

I filed a bugzilla asking the maintainer to bring back the compat library https://bugzilla.redhat.com/show_bug.cgi?id=2150117 but there seems to be a disagreement about the full impact here.

I think this removal should have been submitted as a self-contained change per https://docs.fedoraproject.org/en-US/program_management/changes_policy/ . I'd like FESCO to review this removal as if it were a self-contained change.

My actual opinion as to removal since I'm unlikely to show up for a meeting:
The change removing/adding the compat library is 24 lines of very easy to understand spec file. There's nothing particularly special here and I'm not seeing an excessive burden on the maintainer. I also realize my opinions on maintainer burden are tainted by years of kernel development.

Fedora aims to provide a usable system and that does include compatibility with 3rd party binaries to some extent. Fedora does not provide a full cross compiled gdb at the moment (because doing so is an actual maintainer burden) and I've always relied on external toolchains for this. I realize there's philosophical discussions about proprietary 3rd party binaries but this is a fully open GCC toolchain. Fedora has put in a large amount of effort to work with the ARM community and not being able to run their opensource toolchains is a step backwards.

Not having ncurses-compat-libs makes Fedora less usable than other distributions. I do not find the symlink solution mentioned for AOSP acceptable. The benefit of providing this library seems to outweigh any minimal costs involved here.

I think the question of "how long do we need to support this" is a valid question that should be discussed via Fedora change policy.

I tend to agree with @labbott's assessment here. Dropping libraries is essentially a world-breaking change, and needs to be announced at the minimum.

Not to mention, as a very non-kernel maintainer, I also agree that ncurses-compat-libs wasn't that much of a burden and provided significant software support.

Proposal: ncurses-compat-libs is restored and a proper Change is requested for removing this package in a future Fedora Linux release.

I agree, though I would like to hear from the maintainer as to why the compat package was removed. If there is a larger issue that needs consideration, we should discuss that.

But yes, ncurses is in the category of what I consider core libraries for a Linux system and are foundational for what other software can expect. I also cannot find a change proposal discussing the removal of the compat libs package, but I would say this is something that should have been a change proposal if it was not. If policy should be updated to indicate a change like this is worthy of a change proposal, we should do that too.

+1 to ngompa's proposal.

I agree that this should have been announced and discussed better.

OTOH if the maintainer no longer wants to maintain it, we cannot force them. Anybody else who needs this is free to package it separately from a nucruses5 component and maintain it instead of them. (Just please don't name it compat.)

Agreed, we can't force the maintainer to do it. But we should be able to propose a contingency plan.

I am also not sure that the creators of the toolchain using these libraries would be aware of the change proposal. We would discuss it, as we should, but the impacts found would be among other Fedora packages. I am not sure if there is a good way to assess the impact of removing a core or foundational library. Maybe it is worth establishing (a) a curated set of packages (and their subpackages) that are in this category and then (b) a deprecation policy for maintainers that want to remove subpackages like this. Just to brainstorm, announce the package is deprecated and will be removed in the next N+1 Fedora release; note that the deprecated packages are deprecated for users that install them or use them (dnf plugin?). I imagine there is something we can do that better communicates these changes to outside users.

FYI ncurses-compat-libs is also required for megacli/storcli to work, which are needed to support LSI hardware raid cards. See https://bugzilla.redhat.com/show_bug.cgi?id=2117930 for the related discussion in RHEL 9.

I'd like o cc @mlichvar here before this gets approved without them even knowing about it.

Metadata Update from @dcantrell:
- Issue tagged with: meeting

This issue will be discussed at the next meeting on 12 Dec 2022.

↑ that should probably be December 13, 2022, unless there's a meeting today that I'm not aware of :)

For what it's worth, I'm +1 to my own proposal (in case it wasn't clear :wink: )

+1 to ngompa's proposal.

(I hope the Change does not get proposed until actually all or almost all users have been weaned off.)

Metadata Update from @dcantrell:
- Issue tagged with: stalled

As discussed in the FESCo meeting today (13-Dec-2022), marked as stalled until we can get feedback from the ncurses package maintainer.

If you agree we need this, I can add it back. How many more years should we keep it? It would be nice to have a Fedora policy covering this topic.

I thought compat packages are normally removed without any formal process as soon as nothing in Fedora is using them. Most libraries are updated to a newer version without any compat packages. 3rd-party software provided in binary form breaks frequently with Fedora updates and it never crossed my mind to request a compat package. There are other distros with long-term ABI compatibility.

My personal opinion (not FESCo's):

  • let's add it back now to revert back to the previous status quo while we figure out the next steps
  • if you want to get rid of it, I support your right to do so, but please communicate it loudly (ideally via a change proposal)
  • if others think this is needed, coordinate with them on creating a separate ncurses5 component that they can maintain (assuming you are OK that it stays considering it is no longer "your problem")

WDYT?

My opinion aligns with @churchyard on this too. Furthermore, I think it's reasonable for us to have a Change to remove it in Fedora Linux 40. That gives people a year to get everything worked out and upgrade.

So… can we close this as "agreed" without an explicit vote? Everyone who commented was positive.

Metadata Update from @zbyszek:
- Issue untagged with: stalled

@mlichvar does my proposal work for you?

Metadata Update from @churchyard:
- Issue untagged with: meeting

https://bodhi.fedoraproject.org/updates/FEDORA-2023-c6973a909a restores the compat libs. Let's close this.

Metadata Update from @zbyszek:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.