On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngomp...@gmail.com> wrote: > > 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.
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@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
