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
