summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-August/007377.html
blob: f848068d44f4e2f6357a8ec6d2efd0bd9858ce8b (plain)
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-dev] Possible failure in our update process
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Possible%20failure%20in%20our%20update%20process&In-Reply-To=%3C1313683381.32131.19.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="007376.html">
   <LINK REL="Next"  HREF="007381.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] Possible failure in our update process</H1>
    <B>Michael Scherer</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Possible%20failure%20in%20our%20update%20process&In-Reply-To=%3C1313683381.32131.19.camel%40akroma.ephaone.org%3E"
       TITLE="[Mageia-dev] Possible failure in our update process">misc at zarb.org
       </A><BR>
    <I>Thu Aug 18 18:03:00 CEST 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="007376.html">[Mageia-dev] Possible failure in our update process
</A></li>
        <LI>Next message: <A HREF="007381.html">[Mageia-dev] Possible failure in our update process
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#7377">[ date ]</a>
              <a href="thread.html#7377">[ thread ]</a>
              <a href="subject.html#7377">[ subject ]</a>
              <a href="author.html#7377">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Le jeudi 18 ao&#251;t 2011 &#224; 12:46 -0300, John Balcaen a &#233;crit :
&gt;<i> Hello,
</I>&gt;<i> 
</I>&gt;<i> I noticed a problem with our update process thanks to bug #2450 [1]
</I>&gt;<i> Here we pushed a update to kipi-plugins package (due to a missing
</I>&gt;<i> requires) but the update ends up in a totally broken installation for
</I>&gt;<i> the end user which was not noticed by me (first in fault) &amp; later by
</I>&gt;<i> QA.
</I>&gt;<i> 
</I>&gt;<i> Currently every package built for updates are done against
</I>&gt;<i> core/release, core/updates and core/updates_testing, here when i
</I>&gt;<i> pushed kipi-plugins update, KDE 4.6.5 was already available in
</I>&gt;<i> core/updates_testing so as expected kipi-plugins get linked against
</I>&gt;<i> KDE 4.6.5 &amp; not against KDE 4.6.3 (available in core/release)
</I>&gt;<i> Since most of actors of the QA are simply installing all packages from
</I>&gt;<i> core/updates_testing  (like me) none of us noticed that it would break
</I>&gt;<i>  without KDE 4.6.5 installed and when probably for first updates
</I>&gt;<i> people are using a &#171; fresh Mageia 1&#187; , with several packages in
</I>&gt;<i> updates_testing in the same moment we can't really expect them to
</I>&gt;<i> removed or reinstall/restore a Mageia 1 for every package available in
</I>&gt;<i> testing.
</I>&gt;<i>
</I>&gt;<i> A workaround (which could also ease work for QA people) would be to
</I>&gt;<i> have some temporary repositories as suggested by bolkm on irc, it
</I>&gt;<i> could be based on SRPM package name but for some project like KDE  it
</I>&gt;<i> would need more hacks since RPMS needed to be builded in a specific
</I>&gt;<i> order.
</I>&gt;<i> 
</I>&gt;<i> The QA user will be able to simply add a new media (like
</I>&gt;<i> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
</I>&gt;<i> will be more easy to test a package &amp; *only* this one.
</I>&gt;<i> 
</I>&gt;<i> Another solution is to rebuild the package when moving in on
</I>&gt;<i> core/updates_release but in that case the package tested by QA is of
</I>&gt;<i> course not the same as the one available previously in testing.
</I>&gt;<i> 
</I>&gt;<i> What do you think ?
</I>
I fail to understand, if kde 4.6.5 was a bugfix only of kde 4.6.3, then
what kind of change would break kipi ? 

If there is a ABI break, then it should not go to updates.


-- 
Michael Scherer

</PRE>



























<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="007376.html">[Mageia-dev] Possible failure in our update process
</A></li>
	<LI>Next message: <A HREF="007381.html">[Mageia-dev] Possible failure in our update process
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#7377">[ date ]</a>
              <a href="thread.html#7377">[ thread ]</a>
              <a href="subject.html#7377">[ subject ]</a>
              <a href="author.html#7377">[ 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>