[Mageia-dev] Possible failure in our update process

[andre999]

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é