Am 27.08.2011 22:19, schrieb Michael Scherer: > Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit : >> Am 04.03.2011 22:30, schrieb Michael Scherer: >>> >>> But we can filter and configure it to be a little more perfect. >>> >>> In a rather autocratic fashion, as the maintainer of rpmlint ( both packages >>> and uptream ), as a packager representative, and as a apprentice dictator >>> ( since there is lots of open position in this sector since a few weeks ), >>> I propose that this become the canonical source for rpmlint configuration. >>> >>> In practice, that mean that false positives will have to be added there, >>> that stuff that are noted as errors need to be set in that package, and >>> any policy changes must be made there. >>> >>> So the question is "how do we deal with evolution ( ie, how do we decide >>> something is now a error, or no longer one". >>> >>> Traditionally, packagers didn't care at all, and so the configuration >>> bitrotted >>> since a long time, and people didn't used it, and I just added false >>> positives >>> when packagers notified it ( ie, almost never, except when I noticed some >>> of >>> them ). >>> I suspect that my lack of communication around that didn't help ( and so >>> people didn't knew they could ask for adding a false positive to the list >>> of error to ignore ). >>> >>> Yet, I think we can do better, so feel free to suggest any mad idea for >>> this. >> What about the following, AFAIK those are deprecated and rpmlint shouldn't >> complain about: > Stumbled upon two more false positives, when using %setup_compile_flags during %build, presumably because it also starts with %setup:
W: setup-not-quiet W: setup-not-in-prep
