diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-August/007611.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-August/007611.html | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-August/007611.html b/zarb-ml/mageia-dev/2011-August/007611.html new file mode 100644 index 000000000..ae00b4adb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007611.html @@ -0,0 +1,173 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Rpmlint configuration, false positives + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Rpmlint%20configuration%2C%20false%20positives&In-Reply-To=%3C1314476547.8998.13.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="007612.html"> + <LINK REL="Next" HREF="007613.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Rpmlint configuration, false positives</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Rpmlint%20configuration%2C%20false%20positives&In-Reply-To=%3C1314476547.8998.13.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Rpmlint configuration, false positives">misc at zarb.org + </A><BR> + <I>Sat Aug 27 22:19:15 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="007612.html">[Mageia-dev] Rpmlint configuration, false positives +</A></li> + <LI>Next message: <A HREF="007613.html">[Mageia-dev] Rpmlint configuration, false positives +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7611">[ date ]</a> + <a href="thread.html#7611">[ thread ]</a> + <a href="subject.html#7611">[ subject ]</a> + <a href="author.html#7611">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit : +><i> Am 04.03.2011 22:30, schrieb Michael Scherer: +</I>><i> > +</I>><i> > +</I>><i> > But we can filter and configure it to be a little more perfect. +</I>><i> > +</I>><i> > In a rather autocratic fashion, as the maintainer of rpmlint ( both packages +</I>><i> > and uptream ), as a packager representative, and as a apprentice dictator +</I>><i> > ( since there is lots of open position in this sector since a few weeks ), +</I>><i> > I propose that this become the canonical source for rpmlint configuration. +</I>><i> > +</I>><i> > In practice, that mean that false positives will have to be added there, +</I>><i> > that stuff that are noted as errors need to be set in that package, and +</I>><i> > any policy changes must be made there. +</I>><i> > +</I>><i> > So the question is "how do we deal with evolution ( ie, how do we decide +</I>><i> > something is now a error, or no longer one". +</I>><i> > +</I>><i> > Traditionally, packagers didn't care at all, and so the configuration bitrotted +</I>><i> > since a long time, and people didn't used it, and I just added false positives +</I>><i> > when packagers notified it ( ie, almost never, except when I noticed some of +</I>><i> > them ). +</I>><i> > I suspect that my lack of communication around that didn't help ( and so +</I>><i> > people didn't knew they could ask for adding a false positive to the list +</I>><i> > of error to ignore ). +</I>><i> > +</I>><i> > Yet, I think we can do better, so feel free to suggest any mad idea for this. +</I>><i> +</I>><i> What about the following, AFAIK those are deprecated and rpmlint shouldn't +</I>><i> complain about: +</I>><i> +</I>><i> *files-attr-not-set* as i was told by dmorgan, empty default attributes +</I>><i> (%defattr(-,root,root)) +</I>><i> are useless and not needed, but without it rpmlint complains with this warning +</I>><i> for every file. +</I>><i> What's the status quoe here? rpmlint issue or maybe an rpm bug? +</I>><i> Empty %defattr still needed or not and if not, could you make that warning an +</I>><i> exception? +</I> +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. + +><i> *no-%clean-section* +</I>><i> *no-cleaning-of-buildroot %clean *related to the former, as %clean is not +</I>><i> needed anymore, +</I>><i> because it's done automagically by rpm as a builtin +</I> +Already filtered : +# %clean is now optional, and set by default to a proper value +addFilter('no-%clean-section') + +><i> All the following should be deprecated by filetriggers: +</I>><i> +</I>><i> *library-without-ldconfig-postin +</I>><i> library-without-ldconfig-postun +</I> +Already filtered : +addFilter('library-without-ldconfig-postin') +addFilter('library-without-ldconfig-postun') + +><i> menu-without-postin +</I>><i> menu-without-postun* +</I> +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> +</I>><i> I think the following are bogus, but i may be totally wrong: +</I>><i> +</I>><i> *strange-permission * for SOURCES and SPEC it complains if not 0644, why +</I>><i> is that? +</I> +The question is rather, "why should another permission be used ?". If +not, we can end with 700 or anything weird. + + +><i> *%ifarch-applied-patch* if the build is broken only for i586 for example, +</I>><i> what's wrong about the %ifarch? +</I>><i> Or maybe i don't get the description fully: +</I>><i> +</I>><i> /Patches must be applied on all architectures and may contain +</I>><i> necessary configure and/or code patch to be effective only on a given arch./ +</I>><i> +</I>><i> With the last part of the explanation and the warning itself, i'm confused. If +</I>><i> it is only effective on one arch and fixed build there, why apply it blindly to the other +</I>><i> where this may break build +</I>><i> or have other unwanted sideeffects? +</I> +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 + +</PRE> + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="007612.html">[Mageia-dev] Rpmlint configuration, false positives +</A></li> + <LI>Next message: <A HREF="007613.html">[Mageia-dev] Rpmlint configuration, false positives +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7611">[ date ]</a> + <a href="thread.html#7611">[ thread ]</a> + <a href="subject.html#7611">[ subject ]</a> + <a href="author.html#7611">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |