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.
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.
_______________________________________________
devel mailing list --devel(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedora...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue