[Mageia-dev] Possible failure in our update process

Sat Aug 27 23:46:01 CEST 2011

Le jeudi 18 août 2011 17:46:06, 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 ?
+> 
+> 
+
+If I understand correctly, the problem is when several packages interfere with 
+each other. One thing that could help would be that after submit each update 
+candidate be checked by a script that would :
+- detect BuildRequires that are present in updates_testing
+- (needed ?) detect Requires that are present in updates_testing
+
+When there are such dependencies that come from updates_testing, it means that 
+they have not been pushed to updates yet, and that the update candidate that 
+is being checked must be treated with care.
+
+In kipi-plugins case, maybe following such a check, we would have decided to 
+ship it as part of the big KDE update and not as a standalone update.
+
+The updates policy would have to be adapted so that this check becomes part of 
+every update candidate validation.
+
+I'm not sure this is a good idea, but I'm sending it to you all the same :)
+
+Samuel
+