On 06/12/2022 20:21, Josh Boyer wrote:
On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote:
On Tue, 6 Dec 2022 at 13:50, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
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:
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.
I think he would be happy with the policy spelled out in any form. Something like:
While the Fedora Project is the upstream of CentOS Stream and Red Hat Enterprise Linux, it does not give any guarantees of its releases being compatible with either. Software built in either may not work due to missing dependencies, changes in kernel, compile time or library options, or similar issues.
Ah! Yes, making that clear would be good.
As a guideline that sound a bit woolly to me and doesn't sound useful to
maintainers. As an rough idea either:
While the Fedora Project is the upstream of CentOS Stream and Red Hat Enterprise Linux it does not attempt to provide any compatibility with any major current and past versions of Red Hat Enterprise Linux (currently 7, 8, 9) or any other Linux distribution. Software binaries built for these generic systems may or may not work.
or
The Fedora project attempts to provide a small degree of binary program compatibility by means of compat libraries for the major current and past versions of Red Hat Enterprise Linux (currently 7, 8, 9) and the past 2 releases of Fedora only for reasonably some well used (by means of user feed back) external/commercial applications for 2 years after their publication date where this is easy of achieve as simple compat shared library additions and the maintainers of the required packages are willing to provide such packages.
That's probably a bit much for some, but some watered down derivative :)
Having a degree of binary compatibility aids external/commercial producers and makes Fedora more useful to more people.
Just my view.
Actually is there some mechanism that Fedora could work out how many are using compat RPM's ?
I guess this would require some system used by mirrors that would report back number of downloads of each package. Obviously this wouldn't get everything (we have a cache of packages that we user across systems to reduce downloads across the Internet), but might give some metrics to automate such things.
josh
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
