summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-June/005346.html
blob: cc688343d8a7015d73c7a3a30c9ddda402245784 (plain)
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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-dev] Missing packages in Mageia 1. How to backport?
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C1307710311.26948.154.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="005332.html">
   <LINK REL="Next"  HREF="005364.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] Missing packages in Mageia 1. How to backport?</H1>
    <B>Michael Scherer</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C1307710311.26948.154.camel%40akroma.ephaone.org%3E"
       TITLE="[Mageia-dev] Missing packages in Mageia 1. How to backport?">misc at zarb.org
       </A><BR>
    <I>Fri Jun 10 14:51:51 CEST 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="005332.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
        <LI>Next message: <A HREF="005364.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#5346">[ date ]</a>
              <a href="thread.html#5346">[ thread ]</a>
              <a href="subject.html#5346">[ subject ]</a>
              <a href="author.html#5346">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Le vendredi 10 juin 2011 &#224; 11:44 +0100, Colin Guthrie a &#233;crit :
&gt;<i> 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
</I>&gt;<i> &gt; Le jeudi 09 juin 2011 &#224; 10:14 +0100, Colin Guthrie a &#233;crit :
</I>&gt;<i> &gt;&gt; Hi,
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; As I upgrade my various machines (I only really have about 5, so not
</I>&gt;<i> &gt;&gt; that many) I'm running into a few packages that are missing (this is
</I>&gt;<i> &gt;&gt; inevitable).
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; Nothing major just little things like trac and supybot etc.
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; What is the best way to add these packages to the v1 tree?
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; Using backports seems a little odd as this is &quot;unsupported&quot; and we don't
</I>&gt;<i> &gt;&gt; really want to encourage using it as a means to get the missing packages.
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; If we do not want to have people use backports, we wouldn't have added
</I>&gt;<i> &gt; it in the first place.
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; I do think backport is perfectly suited for that.
</I>&gt;<i> 
</I>&gt;<i> So the user that just wants to install supybot has to expose themselves
</I>&gt;<i> to the risk of updating to a backported version of gnome or KDE.... this
</I>&gt;<i> is hardly ideal. Especially for novice users.
</I>
One alternative would be to make sure that backports for version 1 are
fully supported and break nothing. 

&gt;<i> &gt;&gt; release is obviously frozen so no go there.
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; The only real option is updates, but that should obviously have some QA
</I>&gt;<i> &gt;&gt; on it.
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; Updates is not for new version of software, not for new softwares. And
</I>&gt;<i> &gt; backporting something from cauldron is not a update.
</I>&gt;<i> 
</I>&gt;<i> This seems like a strange statement as */updates on mdv was allowed to
</I>&gt;<i> have new packages in some cases (I've done it before, although I think
</I>&gt;<i> only for * == contrib), so I don't see why we have to restrict this
</I>&gt;<i> possibility in Mageia.
</I>
contrib/updates was basically not watched at all. People could send
anything without trouble, and there was no policy ( nor any enforcement
). That's not really the best example to use :)


&gt;<i> &gt;&gt; Perhaps we need to have some kind of exemption to get these missing
</I>&gt;<i> &gt;&gt; packages added?
</I>&gt;<i> &gt;&gt;
</I>&gt;<i> &gt;&gt; Does anyone have any opinions on this?
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; Yes, I do.
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; We have used backports in the past for that, and I see no reason to
</I>&gt;<i> &gt; change that.
</I>&gt;<i> 
</I>&gt;<i> This is fine in the regular course of distro evolution, but here we're
</I>&gt;<i> talking about users migrating from Mdv to Mga and finding &quot;stale&quot; Mdv
</I>&gt;<i> packages still installed on their system when they want (and we want to
</I>&gt;<i> provide) a Mageia version. This is very much a special case for this
</I>&gt;<i> transitional period but I feel it's an important one, particularly
</I>&gt;<i> *because* it's the first release.
</I>
All releases are equal. And we warned that we would not be able to do
everything, so of course, we will have problem with those that lived on
Mars under a rock, but I think that most people know that we couldn't
have all.

&gt;<i> I think you're thinking in absolute terms rather than transitional
</I>&gt;<i> terms. In absolute terms I agree with you on principle, but I think we
</I>&gt;<i> need to deal with transitional issues gracefully and not treat them as
</I>&gt;<i> second class considerations.
</I>
It was not clear for me from your mail that this would be temporary. 

So I assume we can agree to enforce the &quot;new packages go to backports
unless very specific and defined exceptions&quot; policy for version 2 of the
release ? 

If this is temporary, it would be ok, provided we follows the usual
rules about handling updates.

As we do not want to have untested rpms backported in */updates, this
mean that package must be checked by QA before ( and proper testing for
a new rpm is more that just checking it doesn't break ). 

So it should follow the proper policy ( once we agreed on that ).

As discussed in the previous thread, that would for example mean that
the packager that submit the backport is not the one testing it and
giving the go, even if he can test before submitting to avoid wasting QA
time.

Since we want to restrict to package that people have used and missed
for upgrade, I would also add that this part should be checked and
requires :
- a bug report saying &quot;upgrade failed due to that&quot;
- if we want to be inclusive, a forum post could do the trick ( provided
it is in english, or a bug referencing the forum )
- package must be kept upgradable from mandriva 2010.1
- ideally, the upgrade path should be tested, but I am pretty sure that
people will not :).

Finally, I would also add that as soon a package is in updates or
release, the usual rules should apply ( ie, no more exception ). If I
push the package to */updates once getmail because it is missing, but
the next package do not go to */updates unless it fullfill the usual
rules. Any following backports goes to */backports. 

And, just to be clear, the policy only apply to version 1, for x86_64
and i586.

One question would be &quot;what is a pacakge requires a complex backport&quot;,
for example, someone yesterday asked for darcs, that requires ghc, that
requires bootstrapping. 

Yes, no ? Why ?

&gt;<i> &gt; If the problem is that backports were too buggy in the past, then we
</I>&gt;<i> &gt; should fix backports process, not bypassing them.
</I>&gt;<i> 
</I>&gt;<i> I don't think this is particularly relevant. Backports are unsupported
</I>&gt;<i> generally. That's a given. 
</I>
Before, it was Mandriva that said &quot;we don't support backport&quot;, but we
can do thing differently.
 
We do offer them, we spoke of the application made by Stormi to manage
backports request ( among others ), and it was asked to install it on
our servers. So to me, for something unsupported, it seems to be rather
well integrated.

So the question is &quot;what do people mean exactly when they say &quot;backports
are unsupported&quot; and what would it change when compared to updates,
which is supported by definition&quot; ?

Ie, I think we as a community support them to some extend, and so we
should explain what can people expect, and what they cannot.
And if possible, in a positive way ( as one issue we had with backport
was that people kept telling &quot;do not use it&quot;, which is why people do not
use it ).

Ie, I have a backport installed, would I receive new version, or not ?
I found a bug, can I fill it in bugs.mageia.org, or not ?
Etc, etc. 


&gt;<i> If we encourage people to enable backports to
</I>&gt;<i> get missing packages (this is very distinct and separate from the
</I>&gt;<i> unsupported backports).
</I>
&gt;<i>From the user point of view, any package he doesn't have is a missing
</I>packages, be it due to upgrade from mandriva or because it was not
packaged when he needed :)


&gt;<i> &gt; And if we start by pushing new version in update, people will soon
</I>&gt;<i> &gt; wonder why the new version of X is in updates, while the new version of
</I>&gt;<i> &gt; Y is not, just because we didn't have X in release and Y was there.
</I>&gt;<i> 
</I>&gt;<i> I very much consider &quot;nothing -&gt; version X&quot; quite different from
</I>&gt;<i> &quot;version X -&gt; version Y&quot;. I don't think it's a hard concept for anyone
</I>&gt;<i> to grasp.
</I>
We kept telling to people that we do not want to place new version in
update, and if we start to do the contrary, this is not really coherent.

So while this can be justified, I think we should take in account
communication with users to clearly explain why we do, and why this is
temporary.

I guess a blog post would do the trick, so would you be volunteer for
that if needed ?

-- 
Michael Scherer

</PRE>






































































<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="005332.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
	<LI>Next message: <A HREF="005364.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#5346">[ date ]</a>
              <a href="thread.html#5346">[ thread ]</a>
              <a href="subject.html#5346">[ subject ]</a>
              <a href="author.html#5346">[ 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>