Zbigniew Jędrzejewski-Szmek wrote:
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
The fix for that inconsistency would be to ban rpmautospec. It just makes
everything more complicated.
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
Generally, it helps to keep all your branches in sync (and with that, I
mean, fast-forwarded to the exact same commit hash – no, it is not a problem
if the changelog for a Fedora release includes an entry for a Rawhide mass
rebuild made after that Fedora release branched, it explains why the Release
number has increased and is otherwise harmless) if you are building the same
versions for all releases (which is typically the one case where you bother
backporting specfile updates across releases at all), and to process pull
requests quickly, before you or rel-eng or another pull request bump the
specfile in Rawhide. Then you rarely have conflicts in %changelog to begin
with.
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
> (e.g. when they want to push some fix or separately from other
> work)
> - people submitting pull requests against src.fp.o MAY also
> include a conversion in the pull request and packagers SHOULD
> merge it.
I am opposed to every part of this proposal. Allowing provenpackagers to
convert existing packages (that they do not explicitly comaintain) would be
particularly rude. I do NOT want any of this automagic (also the various
%auto* macros such as %autosetup) in my specfiles, it just makes my life
harder for no benefit whatsoever.
Kevin Kofler
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue