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é
