mdkapplet summary (was: Re: [Cooker] [PROPOSAL] Non blocking mode for mdkapplet by using light media check)

[Thierry Vignaud]

I'm summarizing the misunderstood points about urpmi db locking with
mdkapplet since lot of people believe wrong things.

"Fabrice Facorat" <fabrice.facorat@gmail.com> writes:

> 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 ?

1) mdkapplet does NEVER run urpmi.addmedia 

2) mdkapplet does NOT perform a "complete" urpmi.updatemedia when
   looking for updates availability; it only update the *update media*
   if needed so that it can know if there really are update or not


mdkapplet (really urpmi.updatemeida) only lock the urpmi DB while
updating the DB, which is usually fast since:

- we only update the few media flaggedf as  "update" (which by default
are: main/updates, contrib/updates & non-free/updates)

- the update media have are not frequently update => usually we'll
  only download MD5SUM => very fast check => very short locking time

- the update media have small synthesis => if downloaded MD5SUM
  differs and thus show that the medium was remotely updated and thus
  need to be locally updated, the acutal update is reasonably fast 


Usually, most of update checking time is spent _AFTER_ updating the
update media, while looking for new updates in refreshed synthesis. At
that stage, the urpmi DB is NOT locked.

> 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.

see above & other answers

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

mdkapplet DOES check for updates in non-blocking mode.

Urpmi.updatemedia only locks the db for a short amount of time (while
it's updating the db, which is mandatory).

mdkapplet does NOT lock the DB when computing updates after update
media were updated.

> 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.

Nice. Do you you know that 

> 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.

Which is wrong since there just can be no updates (the update media
having been updated for new updates for packages not installed on the
user machine) => counter-intuitive ("there're updates" then "sorry
there weren't")
 
> 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. ...

see above for why this is wrong.
 
> 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.

of course it will since urpmi.updatemadia will lock the database.
You've just moved the lock and make the user having a less
user-friendly GUI ("there're updates" then "sorry there weren't").

> 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.

when?

- when mdkapplet is checking the db and rpmdrake is already opened?
  we could try to detect this scenario and silently postpone the
  checking

- when starting rpmdrake while mdkapplet is checking the db?
  we could try to detect this scenario and warn about it

> 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 ...

This is even worse since MandrivaUpdate  will actually lock the urpmi
DB while checking for updates, (even after updating the media)
 
> 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.

we already perform it in a non blocking mode (only updating the media
requires locking)

> 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.

Sorry but you're not understanding how wrong this will look for
beginners, actual end users.
 
> 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 ? ).

That's another issue that have nothing to do with locking the urpmi
db.