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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Backports policy proposal
</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%20proposal&In-Reply-To=%3C1309041705.22020.233.camel%40akroma.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="005999.html">
<LINK REL="Next" HREF="006074.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Backports policy proposal</H1>
<B>Michael Scherer</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1309041705.22020.233.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-dev] Backports policy proposal">misc at zarb.org
</A><BR>
<I>Sun Jun 26 00:41:44 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005999.html">[Mageia-dev] Backports policy proposal
</A></li>
<LI>Next message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6020">[ date ]</a>
<a href="thread.html#6020">[ thread ]</a>
<a href="subject.html#6020">[ subject ]</a>
<a href="author.html#6020">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
><i> Michael Scherer a écrit :
</I>><i> >
</I>><i> > so :
</I>><i> > - cannot be backported if this is not a leaf package, will be revised later
</I>><i> > - cannot be backported if the maintainer say "no", but we assume he say "yes" by default
</I>><i> > - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc )
</I>><i> > - cannot be backported if the package was just created and is thus basically untested in cauldron
</I>><i>
</I>><i> What about corner cases where a potential backport is incompatible with changes introduced in
</I>><i> cauldron ? Should we leave such packages to third parties ? (I would tend to say yes.)
</I>
Give a more precise example.
><i> > - must not prevent upgrade to next release
</I>><i>
</I>><i> I can see where a backport could be a more recent version than in cauldron for the moment. Since
</I>><i> that could make the newer version available to users somewhat sooner. Although by release,
</I>><i> cauldron should have at least as recent a version. Or should we prohibit this ?
</I>><i> (I'm thinking of cases where more recent versions are expected for cauldron before release.)
</I>
If we decide to use the spec from cauldron on stable ( as it seems to be
the sanest way of doing it ), the only way to have a newer version in
stable than in cauldron would be to have the build broken on cauldron.
If we tolerate this, and if no one fix ( because the person that did the
upgrade only care about stable release ), we have a broken build.
So forcing the build to be correct on cauldron would be a stronger
incentive to fix. It seems more desirable to prevent a backport if the
price to pay is to have a potentially broken cauldron package.
><i> > - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports )
</I>><i>
</I>><i> It would be best if one can select individual backports without activating the backports
</I>><i> repositories, as is now the case.
</I>><i> So only the brave (wanting all backports) need activate the backports repositories.
</I>><i>
</I>><i> Agree with everything, except as noted.
</I>><i>
</I>><i> It might be useful to list major packages that should never be backported.
</I>><i> I like the idea of tagging backports in the package name, as well as in the package database.
</I>
We cannot tag in the packages database. Yum do it with a separate sqlite
file, afaik.
And tagging in the package name would be quite tricky to do if we need
to play with %mkrel and release.
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005999.html">[Mageia-dev] Backports policy proposal
</A></li>
<LI>Next message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6020">[ date ]</a>
<a href="thread.html#6020">[ thread ]</a>
<a href="subject.html#6020">[ subject ]</a>
<a href="author.html#6020">[ 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>
|
