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
