[Mageia-dev] Possible failure in our update process

Sun Aug 28 10:31:10 CEST 2011

Samuel Verschelde a écrit :
+> 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
+>
+That's a good idea.  It would avoid the situation where updates won't install 
+because of specified dependancies that are missing.  But such cases won't 
+result in breaks, since such packages won't be installed.
+
+Let's assume that a package functions correctly with the latest updates 
+installed, but it breaks on a system based on the latest release, but without 
+all updates (or packages on the test systems) installed.
+
+If an update installs on a users' system, but it breaks, it indicates that 
+something required is not available.  (Since it did work properly in a certain 
+context.)
+In other words, the requires for the package aren't correct.
+1) It could be that a package required is not specified (directly or indirectly).
+2) It could be that a more recent (or different) version of a specified package 
+is required.
+
+It would be useful to have a script that monitors the package during execution 
+and determines what is called, to give us a list of what packages and versions 
+were used.
+This will show us packages missing in requires.
+As for versions, that is trickier.  Requiring the versions used in the tests 
+would be excessive in many cases.  However if this analysis is done before 
+releasing the update, it would help to more quickly correct broken updates.
+
+Hopefully this analysis helps a bit ? :)
+
+-- 
+André
+