On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk> wrote:
On 05/12/2022 16:00, Jarek Prokop wrote:
On 12/5/22 14:57, Peter Robinson wrote:
On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 05/12/2022 12:39, Terry Barnaby wrote:
I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly compat RPM's ?
Fedora is a bleeding edge distribution. If you need old versions, you
should try CentOS or RHEL.
Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
We still have myriad of VM orchestrating solutions (libvirt, vagrant, gnome-boxes, and
probably others I forgot).
There shouldn't be a problem spinning up a graphical environment of CentOS 7, getting
EPEL and then using the tool.
Maybe the tool would work using the `toolbox` utility using last known good Fedora
version for the tool.
That is just my wild guess however.
This is sometimes the tax for being "too" modern.
If the vendor does not want to support Fedora, we can't be held accountable to fully
support their solution.
Does the software work? Yes? That is great! If not, well… we can't do much without
the source code under nice FOSS license, can we.
Regards,
Jarek
Although yes, there are things like VM's, containers etc. which we use for old
development environments all of these are, IMO, clumsy and awkward to use and difficult to
manage especially within automated build environments that build the complete code for an
embedded system with various CPU's, FPGA's, other tools etc.
I know Fedora is fairly bleeding edge (really too bleeding edge for our uses, but others
are too far behind), but there is obviously going to be a balance here so that Fedora is
still useful to as many people as reasonably possible, hence the question on a policy.
In the particular case I am talking about, libncurses*5.so, this is a fairly common
shared library used by quite a few command line tools. A lot of external/commercial
programs are built on/for Redhat7 as it is a de-facto base Linux platform and programs
built on it will likely work on many other Linux systems. These companies are not going to
build for a version of Fedora, it changes far to fast and would require large amounts or
development/support work because of this. Some of the tools I am using were built/shipped
in Feburary 2022, so we are not talking about old tools here.
I wouldn't expect them to build for a Fedora version. I also wouldn't
expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
work on Fedora either.
My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until most people are not
producing programs for that system at least +nyears and then I guess Redhat8 once that
really becomes a core base platform that external people use. A core list of these (there
are only a few) could be kept somewhere and when one is to be depreciated, or users see
problems when Fedora is updated, a decision on this can be then made with that info. This
would keep the Fedora system relevant for more users needs without too much work. In the
case of ncurses, it is really just putting back into the SPEC file that which was removed
for F37 plus the extra storage on mirrors for the compat RPM's.
As a data point, Red Hat Enterprise Linux 9 does not provide
ncurses-compat-libs. If you can, it would be good to ask your ISVs to
provide a timeline when they will migrate off of a very old version of
ncurses.
josh