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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Backports policy clarification (and discussion)
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20clarification%20%28and%20discussion%29&In-Reply-To=%3C4FD31FB9.6060807%40laposte.net%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="016313.html">
<LINK REL="Next" HREF="016416.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Backports policy clarification (and discussion)</H1>
<B>andre999</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20clarification%20%28and%20discussion%29&In-Reply-To=%3C4FD31FB9.6060807%40laposte.net%3E"
TITLE="[Mageia-dev] Backports policy clarification (and discussion)">andre999mga at laposte.net
</A><BR>
<I>Sat Jun 9 12:04:41 CEST 2012</I>
<P><UL>
<LI>Previous message: <A HREF="016313.html">[Mageia-dev] Backports policy clarification (and discussion)
</A></li>
<LI>Next message: <A HREF="016416.html">[Mageia-dev] Backports policy clarification (and discussion)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16318">[ date ]</a>
<a href="thread.html#16318">[ thread ]</a>
<a href="subject.html#16318">[ subject ]</a>
<a href="author.html#16318">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>blind Pete a écrit :
><i> Samuel Verschelde wrote:
</I>><i>
</I>><i>
</I>>><i> Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit :
</I>>><i>
</I>>>><i> On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde
</I>>>><i> <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>>
</I>>>><i>
</I>>><i> wrote:
</I>>><i>
</I>>>>><i> I think you missed my point. If Mageia 1 "backports" has higher
</I>>>>><i> versions than Mageia 2 "release" (not backports), upgrade can fail
</I>>>>><i> because currently our tools do not take backports from the target
</I>>>>><i> release (mageia 2) into account when upgrading a distro.
</I>>>>><i>
</I>>>><i> In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, that
</I>>>><i> upgrading from a system with 2010.2 Backports was not supported. It may
</I>>>><i> work, but was not recommended.
</I>>>><i>
</I>>>><i> I think we should keep the same policy for the upgrade from Mageia 1 to
</I>>>><i> 2.
</I>>>><i> I.E. Don't use backports if you are planning on later doing an upgrade,
</I>>>><i> rather then a clean install.
</I>>>><i>
</I>>>><i> That way, Mageia 1 users who want firefox 13 can get it, without us
</I>>>><i> having to replace the Mageia 2 iso images with an upgraded installer,
</I>>>><i> that will keep backports enabled for 2, if it was enabled for 1.
</I>>>><i>
</I>
Current tools will correctly update backports much of the time. (From
my experience.)
The tools just need to be reworked somewhat to ensure that backports are
updated correctly all of the time.
>>><i> Regards, Dave Hodgins
</I>>>><i>
</I>>><i> Again, this is not the policy we adopted. When we defined the backports
</I>>><i> policy (together, although it seems most people are just discovering it
</I>>><i> now) we said that we didn't want to have backports that don't work, break
</I>>><i> a system, or prevent upgrade.
</I>>><i>
</I>>><i> However, I think that for DVD upgrade without internet access this is a
</I>>><i> sensible option. But the upgrader should detect the situation itself, not
</I>>><i> hope that the user will read somewhere in the release notes that it's not
</I>>><i> supported.
</I>>><i>
</I>><i> No, just include Cauldron's backport repositories (disabled by default)
</I>><i> inside the DVD iso. Upgrade to the release version, if possible.
</I>><i> If that is not possible, upgrade to the version in backports.
</I>
Cauldron's backport repos will always be empty.
If you introduce a new package, or a new version of an existing package
to Cauldron, it is not, by definition, a backport. Even though the same
version (not counting the revision) may be a backport for previous releases.
So if we do a release update to the latest release, backports will be
replaced by regular packages except in those cases where a newer version
has been introduced into Cauldron. And if we update to Cauldron, all
backports will be replaced by regular packages -- according to our
backport policy.
>><i> And there should be a way for those who have internet access to upgrade
</I>>><i> online *with* backports too.
</I>>><i>
</I>
True, to allow the user to do the release upgrade in one step.
>><i> Samuel
</I>>><i>
</I>
Effectively during release updates, we have to treat backports as
updates to installed backports.
Because dependancies may differ between releases for the backport,
installed backports will always have to be updated.
However many users are in a situation where they cannot do online
updates when installing a release update, (That is my situation.) So
they have to do updates as a separate step.
This means that in would be prudent to always treat backports as updates
to installed backports, even if not doing a release update.
If all backports packages are tagged as backports (in the file name), it
will be relatively easy for the tools to recognize and appropriately
treat backports.
We have to avoid backports of packages that could make the system
unbootable, or the major desktops unstartable, but note that this is
already more than covered in the backport policy, under "packages scope".
In sum, as long as our tools can clearly identify backports, it should
be easy to adapt them to properly treat backports.
So I think the policy should be changed to always tag backports in the
revision part of the file name to facilitate recognition of backports,
such as is usually done for "tainted" packages, and sometimes for "nonfree"
Maybe to facilitate keeping backports up to date, we should ensure that
rpmdrake (and the other tools) include backports in the security and
bugfix options. This may already be the case. (While still treating
them as backports.)
--
André
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="016313.html">[Mageia-dev] Backports policy clarification (and discussion)
</A></li>
<LI>Next message: <A HREF="016416.html">[Mageia-dev] Backports policy clarification (and discussion)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#16318">[ date ]</a>
<a href="thread.html#16318">[ thread ]</a>
<a href="subject.html#16318">[ subject ]</a>
<a href="author.html#16318">[ 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>
|
