Re: Removal of BuildRoot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely
<jwakely@xxxxxxxxxxxxxxxxx> 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.
>

As upstream for rpmlint, I do not believe anyone cares at all about
rpmlint in Fedora. One more warning or error won't mean anything. From
time to time, I have considered making a proper rpmlint policy for
Fedora, but I always decide not to because it's clear that that people
don't care about it and ignore it.

Until we can fail builds on rpmlint errors (as both Mageia and
openSUSE do), it's pointless to consider rpmlint as something that
ensures things stay clean and sane.



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux