https://news.opensuse.org/2013/02/07/heat-up-our-servers-12-3-rc1-is-ready-t...
"Major release allows transactions to be parallelized for better performance. The libzypp backend used by openSUSE was completely rewritten around the new API, allowing a lot of old ugly bugs to be shown the door."
Makes readers think the "rewritten libzypp backend" actually "allows transactions to be parallelized".
But the code says:
/** * We do not pretend we're thread safe when all we do is having a huge mutex */ gboolean pk_backend_supports_parallelization (PkBackend *backend) { return FALSE; }
On 08/02/13 19:35, Cristian Morales Vega wrote:
https://news.opensuse.org/2013/02/07/heat-up-our-servers-12-3-rc1-is-ready-t...
"Major release allows transactions to be parallelized for better performance. The libzypp backend used by openSUSE was completely rewritten around the new API, allowing a lot of old ugly bugs to be shown the door."
Makes readers think the "rewritten libzypp backend" actually "allows transactions to be parallelized".
But the code says:
/**
- We do not pretend we're thread safe when all we do is having a huge mutex
*/ gboolean pk_backend_supports_parallelization (PkBackend *backend) { return FALSE; }
Thanks for the heads up, I'll make sure there is no implication of parallelism in libzypp in the final feature list.
Will
On 02/08/2013 10:00 PM, Will Stephenson wrote:
"Major release allows transactions to be parallelized for better performance. The libzypp backend used by openSUSE was completely rewritten around the new API, allowing a lot of old ugly bugs to be shown the door."
Makes readers think the "rewritten libzypp backend" actually "allows transactions to be parallelized".
Thanks for the heads up, I'll make sure there is no implication of parallelism in libzypp in the final feature list.
Will,
Actually the libzypp backend wasn't really rewritten. Coolo adjusted the old backend to work with the new API. However what I understood from Duncan and Michael is that the target is still to really do a rewrite of the zypp backend around the new API and to introduce the parallelism. When asked for a timeline, they came back with maybe 13.1. But I am not sure if this is really going to happen.
Raymond
Am 09.02.2013 08:11, schrieb Raymond Wooninck:
Actually the libzypp backend wasn't really rewritten. Coolo adjusted the old backend to work with the new API. However what I understood from Duncan and Michael is that the target is still to really do a rewrite of the zypp backend around the new API and to introduce the parallelism. When asked for a timeline, they came back with maybe 13.1. But I am not sure if this is really going to happen.
Oh, if you look at the diff of the zypp backend, it *was* rewritten. libzypp is not thread safe and most likely won't be in the mid term future, but what we're considering is replacing the one big mutex with smaller ones, so it might be possible to make download requests and install requests in parallel. But solving and refresh cache won't work in parallel.
But 90% of the work necessary for that is now in libzypp and not in the PK backend, the backend is doing roughly what it can do with the current zypp, so there is no "rewrite zypp backend" TODO atm.
Greetings, Stephan
On 02/08/2013 10:00 PM, Will Stephenson wrote:
Will, Another item is the following:
"Apper 0.8
Rewritten around new PackageKit, and the software update notifier has been rewritten as a plasmoid. "
Apper wasn't rewritten as a a plasmoid. The old Apper is still there and is the default for openSUSE 12.3. People might start looking for something that is not part of the default setup. The plasmoid is available, as you know, but not really pushed yet. What is new is the integration with the KDE Notification system, that gives a better integration with the system when informing the user that updates are available. From there the update installation can be triggered, but this will still happen through the known Apper interface.
Regards
Raymond
Hi!
2013/2/9 Raymond Wooninck tittiatcoke@gmail.com:
On 02/08/2013 10:00 PM, Will Stephenson wrote: [...] Apper wasn't rewritten as a a plasmoid. The old Apper is still there and is the default for openSUSE 12.3. People might start looking for something that is not part of the default setup. The plasmoid is available, as you know, but not really pushed yet. What is new is the integration with the KDE Notification system, that gives a better integration with the system when informing the user that updates are available.
Well, that was available before too ;-) When you close the Apper window while installations/updates were running, the Sentinel integration would provide nice progress information in the tray. Also, the new update plasmoid is already ready to be used. It only lacks some small UI components (like a scrollbar), which we did not implement due to some Plasma bugs.
From there the update installation can be triggered, but this will still happen through the known Apper interface.
The plasmoid can do that too and handle (most of) the UI for updating. It's pretty cool stuff!
Regarding PackageKit: Stephan Kulow is right with that. And mutex sounds fine. :) For Apt, it is planned to fork multiple processes for parallel actions to avoid problems. And, of course, no backend allows running two write-actions on the database at time. ;-) (But that is also not the reason why parallelization was developed).
Btw: Do the native tools (YaST, zypper) emit a SuggestDaemonQuit() signal on the DBus when packagekitd is running? This could avoid locking issues when pkd is just running but doing nothing. (Many people complained about this...) A simple call like this: gdbus call --system \ --dest org.freedesktop.PackageKit \ --object-path /org/freedesktop/PackageKit \ --method org.freedesktop.PackageKit.SuggestDaemonQuit Will cause PK to quit as soon as it is safe to do so (i.e. only background actions are run). Native tools can probably wait for that, if they see that the package cache is locked and packagekitd is running. Maybe you already knew this, this just came to my mind when I read a bug report from an OpenSUSE user the last time, complaining about this.
Kind regards, Matthias
Am 09.02.2013 17:20, schrieb Matthias Klumpp:
A simple call like this: gdbus call --system \ --dest org.freedesktop.PackageKit \ --object-path /org/freedesktop/PackageKit \ --method org.freedesktop.PackageKit.SuggestDaemonQuit Will cause PK to quit as soon as it is safe to do so (i.e. only
The problem is that this call actually starts PK if it's not yet running.
Greetings, Stephan
Hi!
2013/2/10 Stephan Kulow coolo@suse.de:
Am 09.02.2013 17:20, schrieb Matthias Klumpp:
A simple call like this: gdbus call --system \ --dest org.freedesktop.PackageKit \ --object-path /org/freedesktop/PackageKit \ --method org.freedesktop.PackageKit.SuggestDaemonQuit Will cause PK to quit as soon as it is safe to do so (i.e. only
The problem is that this call actually starts PK if it's not yet running.
Yes, indeed :D My plan for Debian is to check if packagekitd is running and to issue this call only if pkd is running. I haven't created any patch yet (lack of time), but I think this might be a viable concept. Cheers, Matthias
-
Cristian Morales Vega -
Matthias Klumpp -
Raymond Wooninck -
Stephan Kulow -
Will Stephenson