On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwbo...@fedoraproject.org> wrote: > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <ter...@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@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. >
As a practical matter, I generally *do* expect them to be compatible at some level. RHEL is a derivative of Fedora. Otherwise it gets very difficult to use commercial software on a Fedora system. I know plenty of ISVs that have a similar expectation. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
