1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
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>
|