[Cooker] [PROPOSAL] Non blocking mode for mdkapplet by using light media check

[Fabrice Facorat]

This proposal is related to bug #38817 :
https://qa.mandriva.com/show_bug.cgi?id=38817

Many users have issues with mdkapplet locking the urpmi database when
looking for updates. The issue with this is when it happens when users
are willing to install an application. Most of them don't understand
what this locking issue mean, how to fix it, and if this is a bug or
not.

So why does mdkapplet is doing a complete urpmi.addmedia when looking
for updates availability ?

IMHO it should check if the media are newer, but not update the urpmi
database db ... this should be done when the user will start
MandrivaUpdate.

This is really annoying as many times I was trying to install a
package when mdkapplet decide to lookup for updates. At the end,
people end up disabling mdkapplet ... which is bad for security

So let me explain my proposal :

1. mdkapplet should check for updates in non-blocking mode

2. for this, a new option could be add to urpmi.update : --no-lock. This option
will just make urpmi.addmedia download the synthesis file and check if md5sums
and creation time are different between the remote download synthesis and the
local synthesis in urpmi database. Normally this check is read-only, and so
there's no need to lock urpmi database

3. mdkapplet will just notify about new updates availability. as
presently mdkapplet is displaying the list of updates, or what kind of
updates are available, it don't need to update urpmi database. It just
need to know that updates are available.

4. When the user will start MandrivaUpdate, urpmi.addmedia will be run
fully, and this time the urpmi database will be updated ( and thus
locked ). Of course, messages and progress bar are displayed during
the updates :
1. Fetching list of updated packages
2. Computing the list of packages to update
3. ...

Whereas the user may have to wait for the media update once
MandrivaUpdate is started, at least the user won't be blocked when
trying to install packages.
Many users don't understand why the urpmi database is locked, and how
to solve/stop this. For them it's an issue, a bug.

Concerning the fact that starting MandrivaUpdate will take longer, I
don't think this is a big issue especially if messages are displayed,
and the user can see a progress bar. When doing the same thing under
WinXP withing windowsupdate website, it takes also a long time because
it have to scan the system. The same for some others updates programs
under windows like some antivirus ones, etc ...

The only issue with this is the fact that normally mdkapplet will
notify for updates only there are updates packages on the updates
mirrors for the installed packages. If this can be done in a non
blocking mode, this is great. If this is not possible, I don't think
this will be a so big issue. The user will be notified for updates, it
will launched MandrivaUpdate, this one will compute the list of
packages to update, and then MandrivaUpdate will just say that there's
no need to update currently installed packages. IMHO this is not a so
big issue.

Next step will be to implement automatics updates with blacklist
support ( should we update blindly kernel or glibc packages ? ).
Automatic updates means also a way to prevent users from log out or
stop the computer while downloading and installing updates ( PolicyKit
? ).



-- 
Close the World, Open the Net
http://www.linux-wizard.net