On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fed...@kohlvanwijngaarden.nl> wrote:
> >Do you agree it would be safe to remove such conditionals and the code
> >they hold ?
>
> Only if they're purely for Fedora. In many examples you also see a rhel
> conditional and that could be used for EPEL. A good number of packagers
> like to use the same spec since it reduces maintenance burden on
> updates. So in that case the mentioned RHEL/EPEL version should also be
> EOL.
I agree.
I'd just add that the same may apply to the %{rhel} macros too - Is
there any need to check for *EOLed* RHEL releases?
> I'm not sure this is great. For example, it may introduce revbumps,
> which can cause a package rebuild but in the resulting RPM these should
> make no difference (otherwise they wouldn't be safe).
>
> To me the right time is to on version bump of a package where you're
> already making changes anyway.
I don't see a need to make a bump and build for every change, only for
changes that are expected to be built.
There are mass rebuilds anyway, so it will be bumped and built eventually.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fed...@kohlvanwijngaarden.nl> wrote:
>
> On Thu, Jan 19, 2023 at 11:52:04AM +0100, Michal Schorm wrote:
> >While playing around with Sourcegraph, which indexed all Fedora
> >package repositories, I was able to craft a query listing all '%if'
> >conditionals referencing Fedora releases that reached EOL.
> >
> >https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group
> >
> >I don't believe such conditions have any value and I think we can
> >remove them right away.
> >I think the removal shouldn't affect neither Fedora nor derived
> >operating systems.
> >
> >If removed, they will be preserved in the git history anyway, for
> >anyone seeking historical code.
> >
> >In some cases the conditionals hold patches that could be removed with them:
> >
> >https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all&patternType=regexp&case=yes&sm=0&groupBy=group
> >
> >--
> >
> >Do you agree it would be safe to remove such conditionals and the code
> >they hold ?
>
> Only if they're purely for Fedora. In many examples you also see a rhel
> conditional and that could be used for EPEL. A good number of packagers
> like to use the same spec since it reduces maintenance burden on
> updates. So in that case the mentioned RHEL/EPEL version should also be
> EOL.
>
> >Do you agree that removing obsolete code such as this brings value to
> >the package codebase ?
>
> Yes, RFC 2119 SHOULD sense.
>
> >Would you see a value in e.g. some kind of a robot reminding
> >maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> >check)
>
> I'm not sure this is great. For example, it may introduce revbumps,
> which can cause a package rebuild but in the resulting RPM these should
> make no difference (otherwise they wouldn't be safe).
>
> To me the right time is to on version bump of a package where you're
> already making changes anyway.
> _______________________________________________
> 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
_______________________________________________
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
