[Mageia-dev] Rpmlint configuration, false positives

Sat Aug 27 22:19:15 CEST 2011

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:
+> 
+> *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?
+
+TO be really clean, this should be changed directly in rpmlint upstream
+to remove the check. But as I do not know the various supported version
+for this removal, I will add a filter.
+
+> *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
+
+Already filtered : 
+# %clean is now optional, and set by default to a proper value
+addFilter('no-%clean-section')
+
+> All the following should be deprecated by filetriggers:
+> 
+> *library-without-ldconfig-postin
+> library-without-ldconfig-postun
+
+Already filtered :
+addFilter('library-without-ldconfig-postin')
+addFilter('library-without-ldconfig-postun')
+
+> menu-without-postin
+> menu-without-postun*
+
+no, the menu file is the old menu system, which was replaced by xdg
+menus. This is not handled by filetriggers. So do we really have nothing
+more depending on it ? ( like some obscure wm ? ) 
+
+> 
+> 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?
+
+The question is rather, "why should another permission be used ?". If
+not, we can end with 700 or anything weird. 
+
+
+> *%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?
+
+If the patch is applicable only to one arch because it break the build
+somewhere else, it is likely to be refused upstream. IF not suitable for
+upstream developpers, then it should not be suitable for us.
+
+So no, this one should not be silenced, and rather promoted to upload
+blocking errors.
+
+-- 
+Michael Scherer
+
+