On 02/15/2018 06:19 PM, Jonathan Wakely wrote:
On 15/02/18 11:10 -0500, David Cantrell wrote:
On 02/15/2018 11:02 AM, Jonathan Wakely wrote:
On 15/02/18 08:46 -0500, David Cantrell wrote:
First, I actually don't care if this change is made or not. My
personal
opinion is that it's a nice-to-have cleanup that will probably not
cause
problems, but you never know with that many packages. So that's why I
feel it should be approached using pull requests. We have that
functionality now thanks to Pagure, which is something we *never*
had in
dist-cvs or the former git system. Is that tedious? Yeah, it is. But
pushing a change like that across many packages will not necessarily
explain to package maintainers why that was done. If packages have not
been cleaned up in that amount of time and things are still building, I
question the urgency of the change. Pull requests give package
maintainers an opportunity to be part of this change. Others have
pointed this out too. Otherwise things like this will likely continue
happening and package maintainers will overwhelming remain in the dark
about what changes should be made in spec files.
What's the real benefit to getting each maintainer to remove the tag
themselves via a pull request? After they get the pull request and
understand the motivation they now know about something that should
not be in their spec files. Is it really necessary for them to know a
negative? Should they also remember a list of other tags that
shouldn't be in there, or should we just remove the cruft, make sure
the docs, examples and templates don't have those tags, and move on?
Remaining in the dark about a tag that has no meaning doesn't seem
harmful.
My thinking there is that the PR serves as a way to communicate this
change to package maintainers who have been copying existing spec files
and templates to make new packages. Concern was mentioned that package
maintainers keep using this tag when they don't need to, so the message
has not been received. I think a PR serves as a good way to communicate
that to maintainers.
So remove it from all our specs and templates and let it be forgotten.
People keep copying it from existing specs because nobody has done the
work of removing all the existing uses before now.
Once it's gone we can make rpmlint warn about it, so it doesn't keep
coming back.
Actually, inspired by this thread, rpm will start at least warning about
BuildRoot tag in the next release or so.
The reason for silently ignoring all this time was to allow spec sharing
between old and new rpm versions, but I guess the time has come to bury
it for good.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
