Re: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
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(a)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?
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