Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

Hi,

With the latest release of Fedora37 we were hit with an issue where the 
ncurses-compat-libs RPM had been depreciated. Due to this some of the 
tools we use would no longer install from their respective RPM's or 
their tar based installs would not run as they needed the 
libncurses*5.so shared libraries.

We use a number of software packages for Electronics and Software 
development, some of which are developed by organisations and companies 
outside of Fedora. This includes things like ARM GCC compilers, FPGA 
compilers, PCB tools, manufacturers utilities etc. Many of these are 
built for Redhat7, being a good general and stable base Linux system for 
these companies/organisations to target. There are a few shared 
libraries that are commonly used and ncurses is one of these.

I am wondering what Fedora's policy is on depreciated old shared 
libraries and particularly compat RPM's ?

If there isn't one, for the benefit of users and making Fedora OS more 
generally useful, can I suggest that relatively often used compat RPMS 
are kept available at least while a major base system such as Redhat7 is 
still widely used as a build platform for external 
companies/organisations and/or perhaps for at least 15? years (or some 
defined time) after they become compat RPM's ?

Terry

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 06:45, Terry Barnaby <terry1(a)beam.ltd.uk&gt; wrote:

>  Hi,
>
>  With the latest release of Fedora37 we were hit with an issue where the
> ncurses-compat-libs
>  RPM had been depreciated. Due to this some of the tools we use would no
>  longer install from their respective RPM's or their tar based installs
>  would not run as they needed the libncurses*5.so shared libraries.
>
>  We use a number of software packages for Electronics and Software
>  development, some of which are developed by organisations and companies
>  outside of Fedora. This includes things like ARM GCC compilers, FPGA
>  compilers, PCB tools, manufacturers utilities etc. Many of these are built
>  for Redhat7, being a good general and stable base Linux system for these
>  companies/organisations to target. There are a few shared libraries that
>  are commonly used and ncurses is one of these.
>
>  I am wondering what Fedora's policy is on depreciated old shared libraries
>  and particularly compat RPM's ?
>
>  
The policy is that if there are packagers who are actively going to be able
to maintain the code, AND the code can be built with the current tools in
the build system, it is kept. If the packagers want it but the code can't
be built, then it is removed. If the packagers don't want it but the code
could still be built, it is still removed.

Sometimes the packager isn't willing anymore because they don't need it
anymore in their work. Other times it is because they asked on a list and
no one answered. Or a dozen other reasons.

Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29 weeks.
Getting code to compile for it on newer OS's is harder and packagers
volunteer time is limited.



>  If there isn't one, for the benefit of users and making Fedora OS
> more
>  generally useful, can I suggest that relatively often used compat RPMS are
>  kept available at least while a major base system such as Redhat7 is still
>  widely used as a build platform for external companies/organisations and/or
>  perhaps for at least 15? years (or some defined time) after they become
>  compat RPM's ?
>
>  Terry
>  _______________________________________________
>  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/[e-mail]
>  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

[Florian Weimer]

* Stephen Smoogen:

>  Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
>  weeks. Getting code to compile for it on newer OS's is harder and
>  packagers volunteer time is limited. 
For official information on support life-cycles, please consider this
official resource:

  Red Hat Enterprise Linux Life Cycle
  <https://access.redhat.com/support/policy/updates/errata/>

In particular the “Life-cycle Dates” page.

Thanks,
Florian

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 08:56, Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  * Stephen Smoogen:
>
>  > Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
>  > weeks. Getting code to compile for it on newer OS's is harder and
>  > packagers volunteer time is limited.
>
>  For official information on support life-cycles, please consider this
>  official resource:
>
>    Red Hat Enterprise Linux Life Cycle
>    <https://access.redhat.com/support/policy/updates/errata/>
>
>  In particular the “Life-cycle Dates” page.
>
>  
I was going from

Maintenance SupportRed Hat Enterprise Linux
VersionGeneral availabilityFull support endsMaintenance Support 1
endsMaintenance
Support or Maintenance Support 2 endsExtended life cycle support (ELS)
add-on endsExtended life phase endsFinal minor release
7 June 10, 2014 August 6, 2019 August 6, 2020 June 30, 2024 June 30, 2026
Ongoing 7.9

While there is ELS going to 2026, that is an additional contract outside of
general service.


>  Thanks,
>  Florian
>
>  
-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Peter Robinson]

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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.

[Jarek Prokop]

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&gt;  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

[Terry Barnaby]

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&gt;  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.

My view is that compat versions of the commonly used shared libraries 
for programs that are used on Redhat7 should be kept available until 
most people are not producing programs for that system at least +nyears 
and then I guess Redhat8 once that really becomes a core base platform 
that external people use. A core list of these (there are only a few) 
could be kept somewhere and when one is to be depreciated, or users see 
problems when Fedora is updated,  a decision on this can be then made 
with that info. This would keep the Fedora system relevant for more 
users needs without too much work. In the case of ncurses, it is really 
just putting back into the SPEC file that which was removed for F37 plus 
the extra storage on mirrors for the compat RPM's.


>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]
>  My view is that compat versions of the commonly used shared
> libraries
>  for programs that are used on Redhat7 should be kept available until
>  most people are not producing programs for that system at least
>  +nyears and then I guess Redhat8 once that really becomes a core base
>  platform that external people use. A core list of these (there are
>  only a few) could be kept somewhere and when one is to be depreciated,
>  or users see problems when Fedora is updated,  a decision on this can
>  be then made with that info. This would keep the Fedora system
>  relevant for more users needs without too much work. 
Well, that is still *some* work and someone would have to do it. Are you
volunteering?

>  In the case of ncurses, it is really just putting back into the SPEC
>  file that which was removed for F37 plus the extra storage on mirrors
>  for the compat RPM's. 
If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Terry Barnaby]

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
>  On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
>  [...]
> > My view is that compat versions of the commonly used shared libraries
> > for programs that are used on Redhat7 should be kept available until
> > most people are not producing programs for that system at least
> > +nyears and then I guess Redhat8 once that really becomes a core base
> > platform that external people use. A core list of these (there are
> > only a few) could be kept somewhere and when one is to be depreciated,
> > or users see problems when Fedora is updated,  a decision on this can
> > be then made with that info. This would keep the Fedora system
> > relevant for more users needs without too much work.
>  Well, that is still *some* work and someone would have to do it. Are you
>  volunteering?
>
> > In the case of ncurses, it is really just putting back into the SPEC
> > file that which was removed for F37 plus the extra storage on mirrors
> > for the compat RPM's.
>  If it's "just" that, why don't you do it yourself? Obviously, the
>  current ncurses maintainer decided it was time to drop the old v5 ABI
>  compat libs from the package. However, nothing is stopping you from
>  picking that up and maintaining an "ncurses5" package for as long as you
>  need it.
>
>  Regards,
>  Dominik 
Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of the 
compat lib and we are fine. I haven't separated it out from the main 
ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems like 
the wrong way to do this in general. I have made this available to 
others who will be in the same boat.

But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS is 
likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore external 
and commercial binaries built with say Redhat7 and provide no degree of 
compatibility so be it, but it would be useful for everyone to know 
where the land lies and be on the same page. The maintainer of the 
ncurses package wasn't sure of the policy on this. In my case, a lack of 
being able to easily run particular external/commercial programs built 
for Redhat7 will likely move me further away from working with Fedora 
(using, reporting bugs, promoting it etc.) as it will be a less useful 
system for our usage.

[Vít Ondruch]

Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
>  On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
> > On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
> > [...]
> >> My view is that compat versions of the commonly used shared libraries
> >> for programs that are used on Redhat7 should be kept available until
> >> most people are not producing programs for that system at least
> >> +nyears and then I guess Redhat8 once that really becomes a core base
> >> platform that external people use. A core list of these (there are
> >> only a few) could be kept somewhere and when one is to be depreciated,
> >> or users see problems when Fedora is updated,  a decision on this can
> >> be then made with that info. This would keep the Fedora system
> >> relevant for more users needs without too much work.
> > Well, that is still *some* work and someone would have to do it. Are you
> > volunteering?
> >
> >> In the case of ncurses, it is really just putting back into the SPEC
> >> file that which was removed for F37 plus the extra storage on mirrors
> >> for the compat RPM's.
> > If it's "just" that, why don't you do it yourself? Obviously, the
> > current ncurses maintainer decided it was time to drop the old v5 ABI
> > compat libs from the package. However, nothing is stopping you from
> > picking that up and maintaining an "ncurses5" package for as long as you
> > need it.
> >
> > Regards,
> > Dominik
>
>  Well in this case I have created a suitable compat lib, all I did was 
>  re-introduce the bits to the SPEC file that removed the building of 
>  the compat lib and we are fine. I haven't separated it out from the 
>  main ncurses SPEC through and have only done this locally as I have no 
>  knowledge of the hoops to create a separate package and that seems 
>  like the wrong way to do this in general. I have made this available 
>  to others who will be in the same boat.
>
>  But the purpose of my thread here is a more general Fedora policy 
>  question as it affects users of Fedora as to what applications the OS 
>  is likely to support. If the policy is to just support Fedora built 
>  binaries within the particular version of Fedora and to ignore 
>  external and commercial binaries built with say Redhat7 and provide no 
>  degree of compatibility so be it, but it would be useful for everyone 
>  to know where the land lies and be on the same page. The maintainer of 
>  the ncurses package wasn't sure of the policy on this.
>  

I wonder what is this claim based upon? Could you provide a link? And I 
wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be enforced 
unless there is somebody to pickup the work. So in this case, it should 
be enough to convince the maintainer to revert the changes, shouldn't be?


Vít


>  In my case, a lack of being able to easily run particular 
>  external/commercial programs built for Redhat7 will likely move me 
>  further away from working with Fedora (using, reporting bugs, 
>  promoting it etc.) as it will be a less useful system for our usage.
>  _______________________________________________
>  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/[e-mail]
>  Do not reply to spam, report it: 
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Terry Barnaby]

On 06/12/2022 15:56, Vít Ondruch wrote:
>  Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
> > On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
> >> On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
> >> [...]
> >>> My view is that compat versions of the commonly used shared libraries
> >>> for programs that are used on Redhat7 should be kept available until
> >>> most people are not producing programs for that system at least
> >>> +nyears and then I guess Redhat8 once that really becomes a core base
> >>> platform that external people use. A core list of these (there are
> >>> only a few) could be kept somewhere and when one is to be depreciated,
> >>> or users see problems when Fedora is updated,  a decision on this can
> >>> be then made with that info. This would keep the Fedora system
> >>> relevant for more users needs without too much work.
> >> Well, that is still *some* work and someone would have to do it. Are 
> >> you
> >> volunteering?
> >>
> >>> In the case of ncurses, it is really just putting back into the SPEC
> >>> file that which was removed for F37 plus the extra storage on mirrors
> >>> for the compat RPM's.
> >> If it's "just" that, why don't you do it yourself? Obviously,
> the
> >> current ncurses maintainer decided it was time to drop the old v5 ABI
> >> compat libs from the package. However, nothing is stopping you from
> >> picking that up and maintaining an "ncurses5" package for as long as 
> >> you
> >> need it.
> >>
> >> Regards,
> >> Dominik
> >
> > Well in this case I have created a suitable compat lib, all I did was 
> > re-introduce the bits to the SPEC file that removed the building of 
> > the compat lib and we are fine. I haven't separated it out from the 
> > main ncurses SPEC through and have only done this locally as I have 
> > no knowledge of the hoops to create a separate package and that seems 
> > like the wrong way to do this in general. I have made this available 
> > to others who will be in the same boat.
> >
> > But the purpose of my thread here is a more general Fedora policy 
> > question as it affects users of Fedora as to what applications the OS 
> > is likely to support. If the policy is to just support Fedora built 
> > binaries within the particular version of Fedora and to ignore 
> > external and commercial binaries built with say Redhat7 and provide 
> > no degree of compatibility so be it, but it would be useful for 
> > everyone to know where the land lies and be on the same page. The 
> > maintainer of the ncurses package wasn't sure of the policy on this.
>
>
>  I wonder what is this claim based upon? Could you provide a link? And 
>  I wonder if there was such policy, would the maintainer changed their 
>  mind? I am asking because I don't think that any policy can be 
>  enforced unless there is somebody to pickup the work. So in this case, 
>  it should be enough to convince the maintainer to revert the changes, 
>  shouldn't be?
>
>
>  Vít
>
>
>  
Sorry, what claim ?

I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something that 
is fine. And obviously a Policy may not be enforced, but at least it 
would be a guideline. I understand the maintainer asked a question on 
when to depreciate on this list, but had no replies. He took it that if 
the compat libs were not in use by any Fedora packages for the release 
in question it should/could be depreciated which is one approach.

[Vít Ondruch]

Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):
>  On 06/12/2022 15:56, Vít Ondruch wrote:
> >
> > Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
> >> On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
> >>> On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
> >>> [...]
> >>>> My view is that compat versions of the commonly used shared libraries
> >>>> for programs that are used on Redhat7 should be kept available until
> >>>> most people are not producing programs for that system at least
> >>>> +nyears and then I guess Redhat8 once that really becomes a core base
> >>>> platform that external people use. A core list of these (there are
> >>>> only a few) could be kept somewhere and when one is to be 
> >>>> depreciated,
> >>>> or users see problems when Fedora is updated,  a decision on this can
> >>>> be then made with that info. This would keep the Fedora system
> >>>> relevant for more users needs without too much work.
> >>> Well, that is still *some* work and someone would have to do it. 
> >>> Are you
> >>> volunteering?
> >>>
> >>>> In the case of ncurses, it is really just putting back into the SPEC
> >>>> file that which was removed for F37 plus the extra storage on mirrors
> >>>> for the compat RPM's.
> >>> If it's "just" that, why don't you do it yourself?
> Obviously, the
> >>> current ncurses maintainer decided it was time to drop the old v5 ABI
> >>> compat libs from the package. However, nothing is stopping you from
> >>> picking that up and maintaining an "ncurses5" package for as long
>
> >>> as you
> >>> need it.
> >>>
> >>> Regards,
> >>> Dominik
> >>
> >> Well in this case I have created a suitable compat lib, all I did 
> >> was re-introduce the bits to the SPEC file that removed the building 
> >> of the compat lib and we are fine. I haven't separated it out from 
> >> the main ncurses SPEC through and have only done this locally as I 
> >> have no knowledge of the hoops to create a separate package and that 
> >> seems like the wrong way to do this in general. I have made this 
> >> available to others who will be in the same boat.
> >>
> >> But the purpose of my thread here is a more general Fedora policy 
> >> question as it affects users of Fedora as to what applications the 
> >> OS is likely to support. If the policy is to just support Fedora 
> >> built binaries within the particular version of Fedora and to ignore 
> >> external and commercial binaries built with say Redhat7 and provide 
> >> no degree of compatibility so be it, but it would be useful for 
> >> everyone to know where the land lies and be on the same page. The 
> >> maintainer of the ncurses package wasn't sure of the policy on this.
> >
> >
> > I wonder what is this claim based upon? Could you provide a link? And 
> > I wonder if there was such policy, would the maintainer changed their 
> > mind? I am asking because I don't think that any policy can be 
> > enforced unless there is somebody to pickup the work. So in this 
> > case, it should be enough to convince the maintainer to revert the 
> > changes, shouldn't be?
> >
> >
> > Vít
> >
> >
> >
>  Sorry, what claim ?
>  

My question was specifically about the last sentence of the quote, e.g. 
do you have any link to BZ ticket, ML or anywhere else where this was 
discussed? That would help to get complete picture.


>  I have no issue with the maintainer in this particular instance, as 
>  people have said if a maintainer doesn't want to support something 
>  that is fine. And obviously a Policy may not be enforced, but at least 
>  it would be a guideline. I understand the maintainer asked a question 
>  on when to depreciate on this list, but had no replies.
>  

Ah, so there was ML thread you are referring to. Is it this one?

https://lists.fedoraproject.org/archives/list/[e-mail].o...

And this could also provide more context:

https://bugzilla.redhat.com/show_bug.cgi?id=2150117


>  He took it that if the compat libs were not in use by any Fedora 
>  packages for the release in question it should/could be depreciated 
>  which is one approach.
>  

It seems that Miroslav would consider the change if there was such 
guidelines.

So do you have any specific gudelines draft?

I think this is always the same, if you really want Fedora to do 
something, then it might need to take some action. Sometimes is enough 
to open ticket or send email, other times it means to maintain package 
or draft specific proposal for guidelines. You can even join the Fedora 
governing bodies if you think it will help.

But I still think the best option for you and for the whole Fedora 
community would be if you picked up the compat-ncurses package maintenance.


Vít

[Terry Barnaby]

On 06/12/2022 17:40, Vít Ondruch wrote:
>  Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):
> > On 06/12/2022 15:56, Vít Ondruch wrote:
> >>
> >> Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):
> >>> On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
> >>>> On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
> >>>> [...]
> >>>>> My view is that compat versions of the commonly used shared
> libraries
> >>>>> for programs that are used on Redhat7 should be kept available until
> >>>>> most people are not producing programs for that system at least
> >>>>> +nyears and then I guess Redhat8 once that really becomes a core
> base
> >>>>> platform that external people use. A core list of these (there are
> >>>>> only a few) could be kept somewhere and when one is to be 
> >>>>> depreciated,
> >>>>> or users see problems when Fedora is updated,  a decision on this
> can
> >>>>> be then made with that info. This would keep the Fedora system
> >>>>> relevant for more users needs without too much work.
> >>>> Well, that is still *some* work and someone would have to do it. 
> >>>> Are you
> >>>> volunteering?
> >>>>
> >>>>> In the case of ncurses, it is really just putting back into the SPEC
> >>>>> file that which was removed for F37 plus the extra storage on
> mirrors
> >>>>> for the compat RPM's.
> >>>> If it's "just" that, why don't you do it yourself?
> Obviously, the
> >>>> current ncurses maintainer decided it was time to drop the old v5 ABI
> >>>> compat libs from the package. However, nothing is stopping you from
> >>>> picking that up and maintaining an "ncurses5" package for as
> long 
> >>>> as you
> >>>> need it.
> >>>>
> >>>> Regards,
> >>>> Dominik
> >>>
> >>> Well in this case I have created a suitable compat lib, all I did 
> >>> was re-introduce the bits to the SPEC file that removed the 
> >>> building of the compat lib and we are fine. I haven't separated it 
> >>> out from the main ncurses SPEC through and have only done this 
> >>> locally as I have no knowledge of the hoops to create a separate 
> >>> package and that seems like the wrong way to do this in general. I 
> >>> have made this available to others who will be in the same boat.
> >>>
> >>> But the purpose of my thread here is a more general Fedora policy 
> >>> question as it affects users of Fedora as to what applications the 
> >>> OS is likely to support. If the policy is to just support Fedora 
> >>> built binaries within the particular version of Fedora and to 
> >>> ignore external and commercial binaries built with say Redhat7 and 
> >>> provide no degree of compatibility so be it, but it would be useful 
> >>> for everyone to know where the land lies and be on the same page. 
> >>> The maintainer of the ncurses package wasn't sure of the policy on 
> >>> this.
> >>
> >>
> >> I wonder what is this claim based upon? Could you provide a link? 
> >> And I wonder if there was such policy, would the maintainer changed 
> >> their mind? I am asking because I don't think that any policy can be 
> >> enforced unless there is somebody to pickup the work. So in this 
> >> case, it should be enough to convince the maintainer to revert the 
> >> changes, shouldn't be?
> >>
> >>
> >> Vít
> >>
> >>
> >>
> > Sorry, what claim ?
>
>
>  My question was specifically about the last sentence of the quote, 
>  e.g. do you have any link to BZ ticket, ML or anywhere else where this 
>  was discussed? That would help to get complete picture.
>
>
> >
> > I have no issue with the maintainer in this particular instance, as 
> > people have said if a maintainer doesn't want to support something 
> > that is fine. And obviously a Policy may not be enforced, but at 
> > least it would be a guideline. I understand the maintainer asked a 
> > question on when to depreciate on this list, but had no replies.
>
>
>  Ah, so there was ML thread you are referring to. Is it this one?
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>
>
>  And this could also provide more context:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=2150117
>
>
> > He took it that if the compat libs were not in use by any Fedora 
> > packages for the release in question it should/could be depreciated 
> > which is one approach.
>
>
>  It seems that Miroslav would consider the change if there was such 
>  guidelines.
>
>  So do you have any specific gudelines draft?
>
>  I think this is always the same, if you really want Fedora to do 
>  something, then it might need to take some action. Sometimes is enough 
>  to open ticket or send email, other times it means to maintain package 
>  or draft specific proposal for guidelines. You can even join the 
>  Fedora governing bodies if you think it will help.
>
>  But I still think the best option for you and for the whole Fedora 
>  community would be if you picked up the compat-ncurses package 
>  maintenance. 
I added some ideas for guidelines in a recent list email. But I suspect 
most would not approve :)

Ok, I can look at that, but in this particular instance its seems to be 
a waste of extra effort, extra packages with extra SPEC's and extra 
build time as it is all there in the original SPEC file and this was 
depreciated as it was considered that this is the policy when a compat 
package was not used by any Fedora pure packages.


>  Vít
>
>
>  _______________________________________________
>  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/[e-mail]
>  Do not reply to spam, report it: 
>  https://pagure.io/fedora-infrastructure/new_issue

[Ewoud Kohl van Wijngaarden]

On Tue, Dec 06, 2022 at 03:44:37PM +0000, Terry Barnaby wrote:
> On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:
> >On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
> >[...]
> >>My view is that compat versions of the commonly used shared libraries
> >>for programs that are used on Redhat7 should be kept available until
> >>most people are not producing programs for that system at least
> >>+nyears and then I guess Redhat8 once that really becomes a core base
> >>platform that external people use. A core list of these (there are
> >>only a few) could be kept somewhere and when one is to be depreciated,
> >>or users see problems when Fedora is updated,  a decision on this can
> >>be then made with that info. This would keep the Fedora system
> >>relevant for more users needs without too much work.
> >Well, that is still *some* work and someone would have to do it. Are you
> >volunteering?
> >
> >>In the case of ncurses, it is really just putting back into the SPEC
> >>file that which was removed for F37 plus the extra storage on mirrors
> >>for the compat RPM's.
> >If it's "just" that, why don't you do it yourself? Obviously, the
> >current ncurses maintainer decided it was time to drop the old v5 ABI
> >compat libs from the package. However, nothing is stopping you from
> >picking that up and maintaining an "ncurses5" package for as long as you
> >need it.
> >
> >Regards,
> >Dominik
>
> Well in this case I have created a suitable compat lib, all I did was 
> re-introduce the bits to the SPEC file that removed the building of 
> the compat lib and we are fine. I haven't separated it out from the 
> main ncurses SPEC through and have only done this locally as I have no 
> knowledge of the hoops to create a separate package and that seems 
> like the wrong way to do this in general. I have made this available 
> to others who will be in the same boat.
>
> But the purpose of my thread here is a more general Fedora policy 
> question as it affects users of Fedora as to what applications the OS 
> is likely to support. If the policy is to just support Fedora built 
> binaries within the particular version of Fedora and to ignore 
> external and commercial binaries built with say Redhat7 and provide no 
> degree of compatibility so be it, but it would be useful for everyone 
> to know where the land lies and be on the same page. The maintainer of 
> the ncurses package wasn't sure of the policy on this. In my case, a 
> lack of being able to easily run particular external/commercial 
> programs built for Redhat7 will likely move me further away from 
> working with Fedora (using, reporting bugs, promoting it etc.) as it 
> will be a less useful system for our usage. 
I'm not in charge of policy, but I always assumed it was based on 
technical possibilities (within reason) and people wanting to invest 
time in it.

Open source is for me all based on fixing your own issues and doing it 
in such a way that it others can benefit from it too. If you have a use 
case for something and are willing to spend the time to keep it alive 
while not limiting others, Fedora can support it.

[Kevin Kofler]

Terry Barnaby wrote:
>  Well in this case I have created a suitable compat lib, all I did
> was
>  re-introduce the bits to the SPEC file that removed the building of the
>  compat lib and we are fine. I haven't separated it out from the main
>  ncurses SPEC through and have only done this locally as I have no
>  knowledge of the hoops to create a separate package and that seems like
>  the wrong way to do this in general. I have made this available to
>  others who will be in the same boat. 
Typically, compatibility libraries should not be subpackages of the main 
library. But ncurses is a bit peculiar in that, as I understand it, the 
latest code can still be built with the old ABI. So in that case, it at 
least makes sense to build both from the same SRPM. But only if they are 
going to be maintained by the same maintainer(s), i.e., you should probably 
sign up as a comaintainer for ncurses in Fedora if you want to do it that 
way. And of course only as long as upstream continues supporting building 
for the old ABI. If they drop support, then a separate compatibility package 
with an old version that supports the old ABI will be needed.

        Kevin Kofler

[Terry Barnaby]

On 06/12/2022 16:37, Kevin Kofler via devel wrote:
>  Terry Barnaby wrote:
> > Well in this case I have created a suitable compat lib, all I did was
> > re-introduce the bits to the SPEC file that removed the building of the
> > compat lib and we are fine. I haven't separated it out from the main
> > ncurses SPEC through and have only done this locally as I have no
> > knowledge of the hoops to create a separate package and that seems like
> > the wrong way to do this in general. I have made this available to
> > others who will be in the same boat.
>  Typically, compatibility libraries should not be subpackages of the main
>  library. But ncurses is a bit peculiar in that, as I understand it, the
>  latest code can still be built with the old ABI. So in that case, it at
>  least makes sense to build both from the same SRPM. But only if they are
>  going to be maintained by the same maintainer(s), i.e., you should probably
>  sign up as a comaintainer for ncurses in Fedora if you want to do it that
>  way. And of course only as long as upstream continues supporting building
>  for the old ABI. If they drop support, then a separate compatibility package
>  with an old version that supports the old ABI will be needed.
>
>           Kevin Kofler
>  _______________________________________________ 
Well I don't want to rock the boat with the maintainer, they are just 
doing what they think is expected.

I will just continue with my own local RPM for our own uses and provide 
it for anyone else that is in the same boat as we are.

Terry

[Alexander Ploumistos]

Hello Terry,

On Thu, Dec 8, 2022 at 12:28 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt; wrote:
>  Well I don't want to rock the boat with the maintainer, they are just
>  doing what they think is expected.
>
>  I will just continue with my own local RPM for our own uses and provide
>  it for anyone else that is in the same boat as we are. 
I think that you are about to miss an important opportunity here.
Since you are willing to maintain the package, why not do it within
the distribution? This would give you access to the infrastructure and
the people that can help you with problems down the road. Since you
are forced to use tools that employ old bits of software, it is more
than likely that sooner or later you'll be faced with another
deprecation. When that happens, as a package maintainer you will be in
a better position to do something about it, either by adopting a
package that is going to be retired or by becoming a co-maintainer,
plus you can test your own packages.
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Pack...

Best regards,
A.

[Gary Buhrmaster]

On Thu, Dec 8, 2022 at 1:54 AM Alexander Ploumistos
<alex.ploumistos(a)gmail.com&gt; wrote:

>  I think that you are about to miss an important opportunity here.
+3000 (well, I guess I am only allowed a +1).

For non-niche requirements, I mostly find the
primary maintainers are more than willing to
add interested parties to the maintainers list
(and typically embrace the potentially reduced
maintenance burden on themselves by
sharing the work).

[Josh Boyer]

On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt; 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&gt; 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.

>  My view is that compat versions of the commonly used shared libraries
> for programs that are used on Redhat7 should be kept available until most people are not
> producing programs for that system at least +nyears and then I guess Redhat8 once that
> really becomes a core base platform that external people use. A core list of these (there
> are only a few) could be kept somewhere and when one is to be depreciated, or users see
> problems when Fedora is updated,  a decision on this can be then made with that info. This
> would keep the Fedora system relevant for more users needs without too much work. In the
> case of ncurses, it is really just putting back into the SPEC file that which was removed
> for F37 plus the extra storage on mirrors for the compat RPM's. 
As a data point, Red Hat Enterprise Linux 9 does not provide
ncurses-compat-libs.  If you can, it would be good to ask your ISVs to
provide a timeline when they will migrate off of a very old version of
ncurses.

josh

[Neal Gompa]

On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt; 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&gt; 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!

[Josh Boyer]

On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  >
>  > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt; 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&gt; 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

[Stephen Smoogen]

On Tue, 6 Dec 2022 at 13:50, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:

>  On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  >
>  > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt;
>  wrote:
>  > >
>  > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt;
>  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&gt; 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.



>  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/[e-mail]
>  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

[Josh Boyer]

On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:
>  On Tue, 6 Dec 2022 at 13:50, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
> >
> > On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> > >
> > > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt;
> wrote:
> > > >
> > > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt;
> 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&gt; 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.

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/[e-mail]
>> 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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Terry Barnaby]

On 06/12/2022 20:21, Josh Boyer wrote:
>  On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen
> <ssmoogen(a)redhat.com&gt; wrote:
> >
> >
> > On Tue, 6 Dec 2022 at 13:50, Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
> >> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >>> On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt;
> wrote:
> >>>> On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby <terry1(a)beam.ltd.uk&gt;
> 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&gt; 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/[e-mail]
> >> 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/[e-mail]
> > 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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Stephen Smoogen]

On Wed, 7 Dec 2022 at 15:45, Terry Barnaby <terry1(a)beam.ltd.uk&gt; wrote:

>  On 06/12/2022 20:21, Josh Boyer wrote:
>  > On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt;
>  wrote:
>  >>
>  >>
>  >>>
>  >> 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.
>
>  
The first would be more likely to be accepted over the second. The second
requires packagers to actually test binaries from these other operating
systems, and that is extra work for volunteers.

Fedora is a stone soup project. If people want software to be in the
operating system, they have to bring it and keep it working themselves.
Once it is in, people will try to help out when they can, but time
resources to use stuff outside of what they normally do is usually not
wanted. There are probably 8 people who are paid to work 'full-time' on
Fedora, and most of their work is just keeping the build systems going.
Everyone else is a volunteer or paid to work on it after everything else
they have done is finished.



>  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.
>  
No, there is no method to see what software is installed or used on
workstation systems.  The community has been overall very adverse to
wanting that, and when we had some software which did act as a 'this is
what is used' actively filled its database full of crap data. Attempts to
add things like 'popcorn' and such usually end with long legal discussions
and promises to revisit filling out crap data.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Kevin Kofler]

Vitaly Zaitsev via devel 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. 
Or you can just build the compat package you need in a Copr, see, e.g.:
https://copr.fedorainfracloud.org/coprs/kkofler/compat-libgfortran-48/
(which I do not really use anymore, but I have kept the Copr up in case it 
is useful for other people).

        Kevin Kofler

[Michael Cronenworth]

On 12/5/22 5:39 AM, Terry Barnaby wrote:
>  With the latest release of Fedora37 we were hit with an issue where
> the 
>  ncurses-compat-libs RPM had been depreciated. Due to this some of the tools we use 
>  would no longer install from their respective RPM's or their tar based installs 
>  would not run as they needed the libncurses*5.so shared libraries. 
If anyone has a support contact with the following hardware vendors could you tell 
them this?

- Canon
    Their 'ufr2' driver for CUPS depends on ncurses-compat-libs. They push updated

versions as of February 2022 that still depend on it.

- Western Digital / HGST
    Their 'hugo' tool depends on libtinfo.so.5 and the tool is currently
maintained 
and shipped to customers today. The latest version I have from 2021 still depends on it.