On 06/12/2022 20:21, Josh Boyer wrote:
On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen
<ssmoogen(a)redhat.com> wrote:
>
>
> On Tue, 6 Dec 2022 at 13:50, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>> On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
>>>> On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)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(a)lists.fedoraproject.org> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-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.fedoraproject.org
>> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-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.fedoraproject.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-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.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue