From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-August/007377.html | 128 +++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-August/007377.html (limited to 'zarb-ml/mageia-dev/2011-August/007377.html') diff --git a/zarb-ml/mageia-dev/2011-August/007377.html b/zarb-ml/mageia-dev/2011-August/007377.html new file mode 100644 index 000000000..f848068d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007377.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 18 18:03:00 CEST 2011 +

+
+ +
Le jeudi 18 août 2011 à 12:46 -0300, John Balcaen a écrit :
+> Hello,
+> 
+> I noticed a problem with our update process thanks to bug #2450 [1]
+> Here we pushed a update to kipi-plugins package (due to a missing
+> requires) but the update ends up in a totally broken installation for
+> the end user which was not noticed by me (first in fault) & later by
+> QA.
+> 
+> Currently every package built for updates are done against
+> core/release, core/updates and core/updates_testing, here when i
+> pushed kipi-plugins update, KDE 4.6.5 was already available in
+> core/updates_testing so as expected kipi-plugins get linked against
+> KDE 4.6.5 & not against KDE 4.6.3 (available in core/release)
+> Since most of actors of the QA are simply installing all packages from
+> core/updates_testing  (like me) none of us noticed that it would break
+>  without KDE 4.6.5 installed and when probably for first updates
+> people are using a « fresh Mageia 1» , with several packages in
+> updates_testing in the same moment we can't really expect them to
+> removed or reinstall/restore a Mageia 1 for every package available in
+> testing.
+>
+> A workaround (which could also ease work for QA people) would be to
+> have some temporary repositories as suggested by bolkm on irc, it
+> could be based on SRPM package name but for some project like KDE  it
+> would need more hacks since RPMS needed to be builded in a specific
+> order.
+> 
+> The QA user will be able to simply add a new media (like
+> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
+> will be more easy to test a package & *only* this one.
+> 
+> Another solution is to rebuild the package when moving in on
+> core/updates_release but in that case the package tested by QA is of
+> course not the same as the one available previously in testing.
+> 
+> What do you think ?
+
+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
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1