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 ? [1] https://bugs.mageia.org/show_bug.cgi?id=2450 -- Balcaen John Jabber-id: [email protected]
