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
|
<!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=%3CCAONrEtaE2W6%2Buk%3DLh9cZNKB0SPbNx7itYHot9%2BaPLi%3DbBn2r9A%40mail.gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="008091.html">
<LINK REL="Next" HREF="008099.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Meeting tonight</H1>
<B>Thierry Vignaud</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3CCAONrEtaE2W6%2Buk%3DLh9cZNKB0SPbNx7itYHot9%2BaPLi%3DbBn2r9A%40mail.gmail.com%3E"
TITLE="[Mageia-dev] Meeting tonight">thierry.vignaud at gmail.com
</A><BR>
<I>Thu Sep 15 16:12:11 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="008091.html">[Mageia-dev] Meeting tonight
</A></li>
<LI>Next message: <A HREF="008099.html">[Mageia-dev] Meeting tonight
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#8097">[ date ]</a>
<a href="thread.html#8097">[ thread ]</a>
<a href="subject.html#8097">[ subject ]</a>
<a href="author.html#8097">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On 15 September 2011 12:48, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote:
><i> The problem is the situation is a lot more different that what the secteam at
</I>><i> mdv had to face. Would we only need to add "new" dependencies to updated
</I>><i> packages, that would be no big deal and we wouldn't make all this noise, we'd
</I>><i> just copy the deps and that's all. The problem is that we support migration
</I>><i> from Mandriva 2010.2 to Mageia 1, and that causes various situations where
</I>><i> *any* dependency of an updated package can be required to install from Core
</I>><i> Release, so we have to copy the full dependency chain !
</I>
OK.
><i> See Dave's recent mail
</I>><i> about bug 2317 that explains that in more details and gives the possible
</I>><i> solutions to this situation.
</I>
Note that his patch is broken as reported by testers...
"the patch (...) suggested some updates from Backports Testing, even though
the repository was not enabled"
This is why I warned that playing with the algorithm regarding the various
combinaisons of setup media, enabled media, ... in my previous mail
Anyway this patch cannot be accepted as it basically turns Mandriva Update
into rpmdrake, aka from "urpmi --auto-select --update" into:
"urpmi --auto-select --media='*/backports'"
><i> I would be interested (really) by your opinion
</I>><i> about the solution to use among those he suggests,
</I>
see above
><i> or even another one.
</I>
Suggestions:
- investigating using the equivalent of --searchmedia
- reusing the old connectiva upgrade infrastructure in the drakx installer
and release a patched installed (a mageia 1.1) that list mdv packages, remove
them prior to upgrading"
- patch perl-URPM so that foobar-X-Ymga is always newer than foobar-Z-Wmdv
In the first case, we would go with something like r[1-4].diff
warning: unknown impact on startup time & RAM usage (in fact it's not
even tested)
in the second case, that only cover the installer case, we should update
install::steps to favor mga over mdv.
See patches gi0X.diff (untested)
cf perl-install/install/share/upgrade/conectiva.10/* and
install:steps::upgrading_redhat()
But this means releasing an updated installer and updated ISOs...
in the third case, that would mean patching URPM's Pkg_compare(),
ranges_overlap()
& rpmvercmp() and hoping nothing else open coded pkg comparison.
We could do what drakx do when upgrading redhat (which has not
been tested for quite a long time...), that is the live patching of URPM
as always
Should work.
We may want to go the third way anyway for future updates...
And maybe doing the first one too.
><i> As the problem is migration from Mandriva 2010.2, we could also try a 2 levels
</I>><i> solution :
</I>><i> - copy new deps the way mdv did, this will ensure fresh mageia installations
</I>><i> will never face an update problem because of a missing dep
</I>><i> - add to the errata that + warn users in MageiaUpdate by improving the error
</I>><i> message ("you can't install, maybe it's because you have old mdv packages on
</I>><i> your system, here is a way to solve your problem, do this and that..., or even
</I>><i> better catch the failure, do not show it, and try again with release media
</I>><i> added)
</I>
wrongdoing...
>><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>
</I>><i> I think most of us are ready to ask users to add the full media set along with
</I>><i> updates media.
</I>
And still you won't catch the users that won't ask you, that won't read the doc,
...
You can increase the % of end users that will be covered but I fear you
won't even cover 50% of them.
><i> The main difficulty is handling the transition, but this is
</I>><i> doable too. For people who might disable release media, this may be a problem,
</I>><i> but is there really an interesting use case for disabling release media and
</I>><i> activating updates media ?
</I>
Whether it's either interesting or not, some people just do that.
Or play with /etc/urpmi/skip.list.
Another scenario I didn't bring attention upon..
>><i> 2) what's more, its not the time to do so, X months after the release
</I>><i>
</I>><i> 3.5 months, and the release will be supported for the coming 12.5 months, so I
</I>><i> think it's worth finding a solution now.
</I>
Sorry AFAIC after the release is too late by definition
>><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>><i>
</I>><i> Here I don't understand : can't MageiaUpdate make use of the Release media
</I>><i> only when it really performs the installation ? Or only if an update is
</I>><i> ignore/rejected because of a missing dep ? That's extra code, sure, but there
</I>><i> might be ways to do things so that extra CPU and RAM is used only when needed.
</I>
>><i> 7) rpmdrake behavior may change in unforeseen ways
</I>>><i>     (because a a shared algorithm will changes)
</I>><i>
</I>><i> This one I can't tell, I don't know what shared algorithm you are talking
</I>><i> about.
</I>
you're suggering to alter mgaupdate behaviour
however it just uses rpmdrake's code with an update flag.
So altering the former's behaviour will alter the later's behaviour
I don't want to be rude but that "I don't know" is exactly why
I'm warning from the beginning
>><i> Will you provides patches, test scenario and do the testing?
</I>><i>
</I>><i> Patches, not sure. Test scenarios is doable, testing too.
</I>
The faillure of the proposed patch should be a scenario for regression
testing btw.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r1.diff
Type: application/octet-stream
Size: 981 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r2.diff
Type: application/octet-stream
Size: 666 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r3.diff
Type: application/octet-stream
Size: 708 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r4.diff
Type: application/octet-stream
Size: 951 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi01.diff
Type: application/octet-stream
Size: 1077 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi02.diff
Type: application/octet-stream
Size: 1252 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi03.diff
Type: application/octet-stream
Size: 891 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi04.diff
Type: application/octet-stream
Size: 812 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0007.obj>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="008091.html">[Mageia-dev] Meeting tonight
</A></li>
<LI>Next message: <A HREF="008099.html">[Mageia-dev] Meeting tonight
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#8097">[ date ]</a>
<a href="thread.html#8097">[ thread ]</a>
<a href="subject.html#8097">[ subject ]</a>
<a href="author.html#8097">[ 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>
|
