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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Meeting tonight
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3C201109151248.01701.stormi%40laposte.net%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="008119.html">
<LINK REL="Next" HREF="008097.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Meeting tonight</H1>
<B>Samuel Verschelde</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3C201109151248.01701.stormi%40laposte.net%3E"
TITLE="[Mageia-dev] Meeting tonight">stormi at laposte.net
</A><BR>
<I>Thu Sep 15 12:48:01 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="008119.html">[Mageia-dev] Meeting tonight
</A></li>
<LI>Next message: <A HREF="008097.html">[Mageia-dev] Meeting tonight
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#8091">[ date ]</a>
<a href="thread.html#8091">[ thread ]</a>
<a href="subject.html#8091">[ subject ]</a>
<a href="author.html#8091">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le jeudi 15 septembre 2011 11:26:41, Thierry Vignaud a écrit :
><i> On 14 September 2011 17:50, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote:
</I>><i> > I tend to think that fixing MageiaUpdate would
</I>><i> > be a lot less work than the workaround we are trying to use which :
</I>><i> > - still needs work from the sysadmins
</I>><i> > - gives a lot of work to QA, that would be better used for testing the
</I>><i> > updates - forces us to link a lot of packages if we really want to make
</I>><i> > sure the update never fails
</I>><i>
</I>><i> For now, we are in the same configuration as @ mdv:
</I>><i> the updates must be self host, if they add new
</I>><i> requires, these must be added to the repository to update.
</I>><i>
</I>><i> This was decided a long time ago after thinking
</I>><i>
</I>><i> Some people have the media networks, ie all packages
</I>><i> can be fetched.
</I>><i> Others will have only DVD media and thus only have a subset
</I>><i> of packages.
</I>><i> Other disable certain media.
</I>><i> Other activate some other media (backports).
</I>><i> Some will have non-free and/or tainted enabled, some won't.
</I>><i> Ie there is no guarantee that a packet with new requires
</I>><i> can be updated on all machines as end users will have
</I>><i> a variety of packages subset.
</I>><i>
</I>><i> For almost 10 years MandrivaUpdate == "urpmi --update"
</I>><i> and not "urpmi --auto-select"
</I>><i>
</I>><i> I think that for the already released mga1 we should stick
</I>><i> to the known good old working method, the MDV's one,
</I>><i> rather than inventing a new quick & dirty thing quickly whom we'll
</I>><i> find subtle bugs along the incoming month
</I>
The problem is the situation is a lot more different that what the secteam at
mdv had to face. Would we only need to add "new" dependencies to updated
packages, that would be no big deal and we wouldn't make all this noise, we'd
just copy the deps and that's all. The problem is that we support migration
from Mandriva 2010.2 to Mageia 1, and that causes various situations where
*any* dependency of an updated package can be required to install from Core
Release, so we have to copy the full dependency chain ! See Dave's recent mail
about bug 2317 that explains that in more details and gives the possible
solutions to this situation. I would be interested (really) by your opinion
about the solution to use among those he suggests, or even another one.
As the problem is migration from Mandriva 2010.2, we could also try a 2 levels
solution :
- copy new deps the way mdv did, this will ensure fresh mageia installations
will never face an update problem because of a missing dep
- add to the errata that + warn users in MageiaUpdate by improving the error
message ("you can't install, maybe it's because you have old mdv packages on
your system, here is a way to solve your problem, do this and that..., or even
better catch the failure, do not show it, and try again with release media
added)
><i>
</I>><i> Some suggested removing the --update flag that MgaUpdate
</I>><i> "gives" to urpmi.
</I>><i>
</I>><i> I think most of them ignore what kind of problems that would bring,
</I>><i> they haven't made any tests at all:
</I>
That's why your mail here is very valuable : we can't guess them all (that's
what I meant with "no proof", I should have said "not enough information to
understand with our limited knowledge").
><i>
</I>><i> 1) we know there will be cases where it won't work
</I>><i> (see above those with the DVD media and not the full network
</I>><i> media, some new dependencies won't be found on the DVD, ...).
</I>><i> Multiply by those who have installed 32 DVD, 64 DVD, dual arch DVD,
</I>><i> ... There are lots of different scenarios to deal with ...
</I>
I think most of us are ready to ask users to add the full media set along with
updates media. The main difficulty is handling the transition, but this is
doable too. For people who might disable release media, this may be a problem,
but is there really an interesting use case for disabling release media and
activating updates media ? And if there is one,
><i>
</I>><i> 2) what's more, its not the time to do so, X months after the release
</I>
3.5 months, and the release will be supported for the coming 12.5 months, so I
think it's worth finding a solution now.
><i>
</I>><i> 3) MgaUpdate will be _much_ slower (compare the startup time
</I>><i> of rpmdrake vs MgaUpdate) because all synthesis
</I>><i> have to be parsed, then we need to compute / verify a far greater
</I>><i> number of potential updates ... (and it's _not_ O(n))
</I>><i> just look at how much faster to start is mgaupdate vs rpmdrake)
</I>><i> It will also consume a lot more RAM
</I>
Here I don't understand : can't MageiaUpdate make use of the Release media
only when it really performs the installation ? Or only if an update is
ignore/rejected because of a missing dep ? That's extra code, sure, but there
might be ways to do things so that extra CPU and RAM is used only when needed.
><i>
</I>><i> 4) that means that we must also update mgaonline to change the way
</I>><i> it computes if there any available updates (so that it
</I>><i> doesn't reject/ignore updates with missing Requires that can
</I>><i> be resolved from */release
</I>
Indeed
><i>
</I>><i> 5) That means mgaapplet too will use quite a lot more time in
</I>><i> order to compute if there any updates
</I>><i>
</I>><i> 6) That means mgaaplet will consume more RAM when
</I>><i> it checks the updates (more exactly the son process it
</I>><i> forks)
</I>><i> however people are already complaining about RAM usage
</I>><i> in mgapapplet
</I>><i>
</I>
Not necessarily, if you do it in 2 steps : first compute list without release
media, and if updates have been rejected/ignored because of missing deps, try
again with release media. You will have that extra RAM and CPU usage only when
necessary.
><i> 7) rpmdrake behavior may change in unforeseen ways
</I>><i> (because a a shared algorithm will changes)
</I>
This one I can't tell, I don't know what shared algorithm you are talking
about.
><i>
</I>><i> 8) Fred Lepied, Frederic Crozat & Warly have removed quite
</I>><i> a lot of code everywhere since that policy went years (nearly
</I>><i> a decade ago)
</I>><i> that means there're a lot of tools that need potential patching
</I>><i> (urpmi, rpmdrake, mgaonline, ...)
</I>><i> for eg: checking for missing media, ...
</I>><i>
</I>><i> In short, it's quite a lot more work and quite a lot more risky than
</I>><i> "just" not using the --update "flag" as some think.
</I>
Indeed, I suspected that, I'm just trying to find a solution, and changing
MageiaUpdate and mgaapplet's behaviour is one of the solutions.
><i> They only see that it will be less work for them (the
</I>><i> work previously done by mdv's secteam for years, that is check
</I>><i> for new introduced requires and if yes add them to the update media)
</I>
This is unfair, as said in various places in the previous weeks, migration
from Mandriva 2010.2 to Mageia 1 and the fact that Mageia 1 had a lot less
packages than Mandriva is what is causing the painful situation we have now,
we're just trying to find a way out of this nightmare.
><i> It can just blow up in quite a lot of places:
</I>><i> - Updates that'll work for some and not for others depending
</I>><i> on which media are enabled
</I>><i> - slower Mgaupdate
</I>><i> - Mgaupdate consuming more RAM
</I>><i> - slower Mgaapplet
</I>><i> - Mgaapplet consuming more RAM
</I>><i>
</I>><i> IMHO it's obviously too risky to do such a major change and I failed
</I>><i> to see why we cannot work the mdv way.
</I>><i>
</I>><i> For the _next_ release, we can test & try to use --media and look if:
</I>><i> performance doesn't drop too much
</I>><i> But we'll still have the same issues:
</I>><i> - Disparate media (various DVDs flavour vs network, ...)
</I>><i> - Performance: the fact that one can have quite a lot media:
</I>><i> (3 (or 6 on biarch) updates media vs 9 (or 18 on biarch) media [1]
</I>><i> even 15 or 30 (biarch) media for those who activate
</I>><i> backport ledia [2].
</I>><i> - algorithm consistency: it must work for those who enable backports
</I>><i> and those who don't, for those who enables tainted/non-free but not
</I>><i> non-free/tainted , ....
</I>><i>
</I>><i> This must be thought about.
</I>><i> Will you?
</I>
I'm trying.
><i> Will you provides patches, test scenario and do the testing?
</I>
Patches, not sure. Test scenarios is doable, testing too.
><i>
</I>><i> my 2 cents
</I>
Thanks
Samuel
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="008119.html">[Mageia-dev] Meeting tonight
</A></li>
<LI>Next message: <A HREF="008097.html">[Mageia-dev] Meeting tonight
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#8091">[ date ]</a>
<a href="thread.html#8091">[ thread ]</a>
<a href="subject.html#8091">[ subject ]</a>
<a href="author.html#8091">[ 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>
|
