From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110304/003013.html | 113 ++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110304/003013.html (limited to 'zarb-ml/mageia-dev/20110304/003013.html') diff --git a/zarb-ml/mageia-dev/20110304/003013.html b/zarb-ml/mageia-dev/20110304/003013.html new file mode 100644 index 000000000..3f69e3c0f --- /dev/null +++ b/zarb-ml/mageia-dev/20110304/003013.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Michael Scherer + misc at zarb.org +
+ Fri Mar 4 22:30:36 CET 2011 +

+
+ +
 Hi,
+
+ so as done before on another time and land, I have pushed a rpmlint 
+ specific
+ policy for Mageia, aptly named 'rpmlint-mageia-policy" ( maybe
+ rpmlint-policy-mageia would be better, not sure ).
+
+ For those that do not know, rpmlint is a tool to check a rpm against a 
+ list
+ of rules written in python, that is used on Fedora, Mandriva, opensuse
+ and likely others too. The tool is used on upload to refuse some rpms 
+ based
+ on this rules, and should be used by people to check rpms, to make sure 
+ that
+ no obvious errors is still there. However, this is not a perfect tool,
+ and it can still give false positives, so people should not use without
+ understanding errors.
+
+ 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.
+-- 
+ Michael Scherer
+
+
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1