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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Proposal: Updating released versions (long post)
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Updating%20released%20versions%20%28long%20post%29&In-Reply-To=%3Ci8ls6o%2434h%241%40dough.gmane.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="001021.html">
<LINK REL="Next" HREF="001032.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Proposal: Updating released versions (long post)</H1>
<B>Marc Paré</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Updating%20released%20versions%20%28long%20post%29&In-Reply-To=%3Ci8ls6o%2434h%241%40dough.gmane.org%3E"
TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">marc at marcpare.com
</A><BR>
<I>Fri Oct 8 03:29:59 CEST 2010</I>
<P><UL>
<LI>Previous message: <A HREF="001021.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI>Next message: <A HREF="001032.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1022">[ date ]</a>
<a href="thread.html#1022">[ thread ]</a>
<a href="subject.html#1022">[ subject ]</a>
<a href="author.html#1022">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le 2010-10-07 19:49, Frank Griffin a écrit :
><i> Part of the recent thread about what the desirable release cycle should
</I>><i> be devolved into a discussion of how backports works and whether or not
</I>><i> it's suitable. I'd like to examine this issue.
</I>><i>
</I>><i> The current urpmi repository architecture serves purposes that were
</I>><i> meaningful to Mandriva. It segregates main from contrib for statement
</I>><i> of support reasons, it separates non-free from main for philosophical
</I>><i> reasons, and it separates restricted from main for legal and business
</I>><i> reasons.
</I>><i>
</I>><i> This works pretty well for cooker, where you either want a particular
</I>><i> category of package considered or you don't, but the reuse of this model
</I>><i> for updates, backports, and testing in released versions isn't as good a
</I>><i> fit.
</I>><i>
</I>><i> The root of the problem is that the user base is different. Users of
</I>><i> cooker want the latest and greatest of everything, and have accepted
</I>><i> that if something breaks in cooker, it may stay broken for awhile.
</I>><i> Users of released versions vary all over the map, from people who never
</I>><i> want anything to change to people who want some specific updates to
</I>><i> people who want everything new but want it stable. Users of cooker
</I>><i> rarely think about security updates, because in grabbing everything
</I>><i> available constantly, the security updates are "just there". With users
</I>><i> of released versions, they may have to opt-in for security updates, and
</I>><i> usually want to treat other updates differently.
</I>><i>
</I>><i> I'd like to propose the following model for updating released versions:
</I>><i>
</I>><i> 1) Users should not have to see, except in minor ways, the different
</I>><i> repositories. Urpmi may see them, and advanced or ideologically polar
</I>><i> users may care about them (e.g. free vs non-free), but most users
</I>><i> won't. Instead, let urpmi or rpmdrake have knowledge about all
</I>><i> repositories whether enabled or not, and display the offerings with an
</I>><i> icon, tooltip, or extra column that indicates the status of the package.
</I>><i>
</I>><i> 2) The update tool we give these users should distinguish between
</I>><i> security updates and backports/testing, but present them both. This is
</I>><i> very much like the Windows Update model, where all available fixes are
</I>><i> divided into "Critical System Updates" and "Software Updates". We don't
</I>><i> really have the same support constraints as Mandriva, and there's no
</I>><i> need to automatically disable backports across the board, and not even
</I>><i> present the backports as possibilities.
</I>><i>
</I>><i> 3) Users should be able to enable options for each category
</I>><i> independently. Most users would probably want security updates applied
</I>><i> automatically, but would want to be notified of availability of
</I>><i> backports or testing and choose those manually.
</I>><i>
</I>><i> (Here's the biggie :-) )
</I>><i> 4) We need to enhance the urpmi.recover functionality and bring it fully
</I>><i> into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS
</I>><i> PREVIOUS VERSION (sorry for the caps). If we don't want to be stuck
</I>><i> with trying to reconcile our desire to QA some packages better than
</I>><i> others with some users' desires to at least *try* the newest stuff, then
</I>><i> we need to allow them to move forwards and backwards in the package
</I>><i> history as easily as possible.
</I>><i>
</I>><i> Yes, I know this is problematic. It means that we have to do a really
</I>><i> good job of getting dependencies right. But if the dependencies *are*
</I>><i> right, then this should be doable.
</I>><i>
</I>><i> It means that we need to expand the logic in urpmi that can currently
</I>><i> identify the packages that need to be uninstalled if some other package
</I>><i> is uninstalled so that it can take into account the package it will be
</I>><i> installing in its place (and the other older versions of packages that
</I>><i> it will require), and compare the two lists to produce a "diff".
</I>><i>
</I>><i> It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires
</I>><i> "B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3
</I>><i> with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the
</I>><i> same transaction. This may have a cascading effect. In any event, the
</I>><i> user should be told what's going to be backlevelled, but specifically
</I>><i> *not* see the current urpmi list of everything that will have to be
</I>><i> removed if "A" 1.3 is removed if most of that stuff is simply going to
</I>><i> be replaced with its own previous versions. In other words, rather than
</I>><i> tell the user that removing "A" 1.3 is going to remove half of KDE and
</I>><i> scare the sh*t out of him, just tell him that the following packages are
</I>><i> going to have to be backlevelled as well. If there really are things
</I>><i> that can't be undone and redone, that should be a separate highly
</I>><i> visible prompt.
</I>><i>
</I>><i> This will require some extended transactional support in urpmi, I would
</I>><i> think, because we'd literally have to overrule rpm about pulling stuff
</I>><i> out from under the feet of other packages if we knew we were going to
</I>><i> put it back. That would mean that we'd have the responsibility of
</I>><i> ensuring that the transaction either committed fully from our
</I>><i> perspective, or got fully rolled back.
</I>><i>
</I>><i> This also means that packagers would have to be aware of packages that
</I>><i> reformat their application files as the version increases, and would
</I>><i> have to archive previous versions using some naming scheme so that they
</I>><i> could be restored (and the current version archived) if an uninstall was
</I>><i> requested. Of course, this would require a prompt to the user to inform
</I>><i> him that any configuration changes made since the upgrade would be
</I>><i> lost. We'd probably also have to expand the "rpmnew" concept to be
</I>><i> version-specific.
</I>><i>
</I>><i> Yes, I realize that a couple of clicks could require a *lot* of
</I>><i> processing; but that can happen today, and the user would still get a
</I>><i> prompt about what was going to be done.
</I>><i>
</I>><i> =========================
</I>><i>
</I>><i> If all this were done, updates/backports/testing could be touted as a
</I>><i> "try it" environment. Click on the update(s) you want to try, we'll
</I>><i> tell you what else we're going to have to upgrade as well, and if for
</I>><i> some reason it doesn't work, you click to restore it to version x.x, we
</I>><i> tell you what will also be restored, and we do it. That way, we don't
</I>><i> have to worry about "guaranteeing" perfect quality updates. If we
</I>><i> missed something, and it doesn't work for you, just roll it back.
</I>><i>
</I>><i> This does require access to all previous versions of each package since
</I>><i> release. However, unless we screw up royally on a recurring basis, the
</I>><i> demand for these intermediate packages should be *much* lighter than for
</I>><i> the current versions, so hosting them on a Mageia primary or possibly
</I>><i> the first-tier mirrors should be sufficient.
</I>><i>
</I>><i> It may be that a good implementation of this would require the
</I>><i> availability of significant disk space for translation-related backups
</I>><i> or such, on the root partition or some other designated partition. If
</I>><i> so, we should determine if there is sufficient space, and if not, alert
</I>><i> the user that his choices are to abort the update or else realize that
</I>><i> he won't be able to roll back. Windows XP SPs do this. I don't see a
</I>><i> problem with this, since the current urpmi response to insufficient disk
</I>><i> space is basically to abort the package install but keep going.
</I>><i>
</I>><i> Thoughts ?
</I>><i>
</I>
Hi FranK:
As it seems we keep going in circles on this Romain has arranged the
following so that the threads on this topic become more focussed:
--------------
It has been posted before but I guess it's a good read for anyone
willing to push an argument in this debate:
<A HREF="http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/">http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/</A>
It is a nice post explaining the existing different point of views
(bonus to clever points about updates frequency and presentation).
Now, in the same vein, let's put the discussion at rest a little and
have each interested person write down an article with arguments for
the why's and how's. So here is a page for that:
<A HREF="http://mageia.org/wiki/doku.php?id=rollingdebate">http://mageia.org/wiki/doku.php?id=rollingdebate</A>
Please write down your point of view, detail it as explained on the
wiki page, link it and a week from now, everyone involved in the
discussion can have a look at it for a summary.
That won't trigger a change decision at once (way too soon anyway, we
have to roll a first release to assess our new build system and
infrastructure and organisation) but it may at least lay down all
arguments and allow to have a better view of what everyone understand,
agree on definitions and see what is really at stake here. For later
reference, discussion and decision.
Thanks a lot.
Cheers,
Romain
--------------
Marc
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="001021.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI>Next message: <A HREF="001032.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1022">[ date ]</a>
<a href="thread.html#1022">[ thread ]</a>
<a href="subject.html#1022">[ subject ]</a>
<a href="author.html#1022">[ 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>
|
