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
|
<!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=%3Ci8p4l8%241b9%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="001053.html">
<LINK REL="Next" HREF="001070.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=%3Ci8p4l8%241b9%241%40dough.gmane.org%3E"
TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">marc at marcpare.com
</A><BR>
<I>Sat Oct 9 09:12:39 CEST 2010</I>
<P><UL>
<LI>Previous message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI>Next message: <A HREF="001070.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1054">[ date ]</a>
<a href="thread.html#1054">[ thread ]</a>
<a href="subject.html#1054">[ subject ]</a>
<a href="author.html#1054">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le 2010-10-09 03:05, Margot a écrit :
><i> On Sat, 09 Oct 2010 02:15:18 -0400
</I>><i> andré<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">andr55 at laposte.net</A>> wrote:
</I>><i>
</I>>><i> Marc Paré a écrit :
</I>>>><i>
</I>>>><i> Le 2010-10-08 23:45, andré a écrit :
</I>>>>><i> Frank Griffin a écrit :
</I>>>>>><i> Marc Paré wrote:
</I>>>>>>><i> Thanks. So this thread is to see if there were a possibility
</I>>>>>>><i> to programme a more efficient roll-back option so that it
</I>>>>>>><i> would be more "aware" of the previous "dependencies" needs
</I>>>>>>><i> for the previous version. Having "double dependencies" is
</I>>>>>>><i> not so much of a problem, it is the rollback to a previous
</I>>>>>>><i> version where the dependency confusion may occur, and, ONLY,
</I>>>>>>><i> if an upgraded type of "dependency" thread had been
</I>>>>>>><i> installed. (Sorry I may have used the wrong terms in the
</I>>>>>>><i> last sentence).
</I>>>>>><i> Well, sort of. It's not an issue of efficiency, but of
</I>>>>>><i> convenience and just making it possible to do without
</I>>>>>><i> resorting to manual use of the rpm
</I>>>>>><i> command.
</I>>>>>><i>
</I>>>>>><i> The rpm command "knows" that a new version replacing the old
</I>>>>>><i> version supplies the same things that the old one did, so it
</I>>>>>><i> will quietly allow the upgrade. It will also do what we need,
</I>>>>>><i> i.e. go the other way and replace a newer version with an
</I>>>>>><i> older one if you use the --oldpackage keyword. We just need
</I>>>>>><i> urpmi to support its use
</I>>>>><i>
</I>>>>><i> One thing that could facilitate this process, if the computer
</I>>>>><i> has a lot of free disk space, is to rename the files being
</I>>>>><i> removed (copying the configuration files), instead of erasing
</I>>>>><i> them. Although they will probably have to be erased
</I>>>>><i> eventually, since no computer has unlimited disk space.
</I>>>>><i> Keeping them long enough that a roll-back is no longer
</I>>>>><i> probable could be workable. Then a roll-back could be done
</I>>>>><i> very quickly, since the files are already on disk, and
</I>>>>><i> presumably reliably. Of course, if new data has been entered,
</I>>>>><i> and the format has been changed, this could be problematic.
</I>>>>><i> Note that configuration files that have been changed from the
</I>>>>><i> installation default are often already saved. (Generally
</I>>>>><i> ".old" is appended to the configuration file name, sometimes
</I>>>>><i> ".new" to the new configuration file.) This of course adds the
</I>>>>><i> maintenance task of removing the old files at some point - it
</I>>>>><i> could be done automatically according to some criteria, or the
</I>>>>><i> user could have to do it manually, perhaps after being
</I>>>>><i> prompted about it.
</I>>>>><i>
</I>>>>><i> (This rollback capability occurs with Microsoft products. The
</I>>>>><i> saved files are only removed manually, on user initiative,
</I>>>>><i> which partly explains the bloated size of a Microsoft
</I>>>>><i> installation over time.)
</I>>>>><i>
</I>>>>><i> If renaming-instead-of-deleting is implemented, perhaps a "do
</I>>>>><i> not keep old program files (useful if limited disk space)"
</I>>>>><i> checkbox option would be useful for computers with less free
</I>>>>><i> disk space. Of course how much disk space is usable to save
</I>>>>><i> old programs on a computer depends on the disk space usage for
</I>>>>><i> other purposes over time.
</I>>>>><i>
</I>>>>><i> my 2 cents :)
</I>>>>><i>
</I>>>>><i> - André (andre999)
</I>>>><i>
</I>>>><i> Not sure about this process. Instead of making it easier for a
</I>>>><i> user, this would now make it more difficult to do and add
</I>>>><i> another layer of knowledge for the new user. It would have to
</I>>>><i> be a little more seamless than this.
</I>>>><i>
</I>>>><i> If there were a way at setup to establish the amount of
</I>>>><i> remaining disk space at installation time, and if there were
</I>>>><i> enough space to allow rollbacks without compromising the
</I>>>><i> installation, then I guess the rollback could then be
</I>>>><i> activated. The user could then be advised at this point that
</I>>>><i> this was activated. If there was not enought disk space, a
</I>>>><i> message could warn the user that software rollbacks would not
</I>>>><i> be possible for lack lack of diskspace.
</I>>><i> The problem is not establishing the current free disk space, but
</I>>><i> how much to leave for use as temporary disk space for other
</I>>><i> applications. For example, if an enduser likes editing numerous
</I>>><i> large video files at the same time (maybe he makes movies), he
</I>>><i> could need a very large amount of temporary free disk space.
</I>>><i> Another user, with the same programs installed, might do
</I>>><i> primarily word processing and Internet, and only occasionally
</I>>><i> edit small videos, thus only needing a relatively small amount of
</I>>><i> temporary disk space. Of course, there could be an automatic
</I>>><i> default, adjustable via a configuration file.
</I>>>><i>
</I>>>><i> I guess then, in the MCC, if a user used the Backports and
</I>>>><i> installed backported software, the rollback amount of diskspace
</I>>>><i> could also be monitored at this level with perhaps an option to
</I>>>><i> delete old programs that are now working well in their updated
</I>>>><i> form.
</I>>><i> This sort of makes sense -- but it is not only the newly
</I>>><i> installed program which is of concern, but also other programs
</I>>><i> which may have the same dependancies (not counting the versions).
</I>>><i> It could take a considerable time before these other programs are
</I>>><i> executed, so it becomes a bit tricky.
</I>>><i> Probably why Microsoft decided to keep such programs by default.
</I>>><i>
</I>>><i> Essentially that is why I would prefer backports to use versions
</I>>><i> of dependancies which correspond to the distro release. A bit
</I>>><i> more work for packagers, but a much more stable system.
</I>>><i> Then the rollback system would only affect the backported program
</I>>><i> and any programs directly dependant on that version. The problem
</I>>><i> becomes much simpler.
</I>>><i> Once the backported and dependant programs (which would be known
</I>>><i> in the database) have all been run without crashing, the user
</I>>><i> could be asked if the programs all worked satifactorily and it
</I>>><i> was ok to delete the backup.
</I>>><i>
</I>>>><i> I guess this would take a bit of coding. But at least the use
</I>>>><i> of Backports would make a little more sense with a rollback
</I>>>><i> option in case an updated software installation did not work
</I>>>><i> out.
</I>>><i> I definitely like the idea of a rollback option.
</I>>><i> However, another option which I would like to see is simply
</I>>><i> leaving the old program in place where possible without conflicts
</I>>><i> - and prompting for its deletion after the backport and
</I>>><i> dependancies have been run (with the same sort of information
</I>>><i> displayed) -- when rpmdrake/urpmi is subsequently accessed.
</I>>><i> In the case of problems with the backport, one would simply run
</I>>><i> the old program, which is still in place.
</I>>><i> Of course, there will often be conficts such that the old program
</I>>><i> can not be left in place, making rollbacks still useful.
</I>>>><i>
</I>>>><i> Marc
</I>>><i> - André (andre999)
</I>><i>
</I>><i> There are already various options which can be run with urpmi, such
</I>><i> as --noclean and --repackage (see man urpmi) and perhaps these
</I>><i> could be incorporated into the GUI - with full simple explanations
</I>><i> for the user on exactly what will happen if those options are
</I>><i> chosen.
</I>><i>
</I>><i> For example:
</I>><i> "Select this option if you want to save the old version of the
</I>><i> package that is being updated. If there is a problem with the new
</I>><i> version, you will be able to uninstall it and go back to the older
</I>><i> version. Warning: this option will use extra space on your disk."
</I>><i>
</I>><i> There could then be a list available showing all the saved older
</I>><i> versions of packages - if, for instance, a user had saved 10 older
</I>><i> versions of Firefox and knew that the most recent one worked
</I>><i> perfectly, they could then safely delete the 9 older versions to
</I>><i> reclaim some disk space.
</I>><i>
</I>
I guess both of your suggestions would work André and Margot.
So, this sounds like it could be something that could be worked out. I
would prefer, as a user, Margot's process. Of course the user would have
to be able to see the usage and re-claimed space due to his use or
Backports. Just to keep informed.
Marc
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI>Next message: <A HREF="001070.html">[Mageia-dev] Proposal: Updating released versions (long post)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1054">[ date ]</a>
<a href="thread.html#1054">[ thread ]</a>
<a href="subject.html#1054">[ subject ]</a>
<a href="author.html#1054">[ 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>
|
