On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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. That compatibility degrades over time though. At this point in time, with RHEL 7 being almost 9 years old, I would not expect software built on RHEL 7 to work on any supported Fedora version. If it does work, that's fantastic and a testament to Fedora, but people should not have that expectation. Terry is politely asking for a policy that would set that expectation. I think the intention is good, but I don't believe it to be realistic. To perhaps illustrate the point further, Red Hat Enterprise Linux does not support applications built on version X-1 running on X unless it is constrained to using a very very small set of dependencies (glibc, libgcc/libstdc++, and a few smaller libraries). Again, it may work fine but the expectation and support policies set for RHEL are (simplified) build on X, run on X where X is within a major version. Our full documentation on this is available in the Application Compatibility Guides. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
