On Thu, Jan 19, 2023 at 04:13:02PM +0100, Michal Schorm wrote:
On Thu, Jan 19, 2023 at 4:04 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora@xxxxxxxxxxxxxxxxxxxxx> 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?
That's what I also suggested.
In Fedora we can reasonably say we mostly care about EPEL and if that
goes EOL then it's actually removed from the mirrors.
In theory people could keep the spec compatible so users can manually
rebuild for older release, even if Fedora infrastructure doesn't. Hence
why I suggested SHOULD rather than MUST.
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.
I'm used that for each release there is also a build. My assumption was
that rpmautospec would create a release, but if it's skipped then my
objection would be gone.
To be clear, I'd actually like to see robots sending in pull requests.
Many version bumps are actually trivial and the-new-hotness could send a
pull request. In a similar way I can see some sort of nanny cleaning up
specs in an automated fashion doing the same. For example, conversion to
SPDX license tags feels like a good candidate (if there's no ambiguity).
If this is automated then it should be easy to opt-out on a repository
basis.
On Debian there is lintian-brush[1] which has a similar objective.
[1]: https://salsa.debian.org/jelmer/lintian-brush
_______________________________________________
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
