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:
*files-attr-not-set* as i was told by dmorgan, empty default attributes
(%defattr(-,root,root))
are useless and not needed, but without it rpmlint complains with this warning
for every file.
What's the status quoe here? rpmlint issue or maybe an rpm bug?
Empty %defattr still needed or not and if not, could you make that warning an
exception?
*no-%clean-section*
*no-cleaning-of-buildroot %clean *related to the former, as %clean is not
needed anymore,
because it's done automagically by rpm as a builtin
All the following should be deprecated by filetriggers:
*library-without-ldconfig-postin
library-without-ldconfig-postun
menu-without-postin
menu-without-postun*
I think the following are bogus, but i may be totally wrong:
*strange-permission * for SOURCES and SPEC it complains if not 0644, why
is that?
*%ifarch-applied-patch* if the build is broken only for i586 for example,
what's wrong about the %ifarch?
Or maybe i don't get the description fully:
/Patches must be applied on all architectures and may contain
necessary configure and/or code patch to be effective only on a given arch./
With the last part of the explanation and the warning itself, i'm confused. If
it is only
effective on one arch and fixed build there, why apply it blindly to the other
where this may break build
or have other unwanted sideeffects?
