Network operations are very non-deterministic: the can finish almost instantly, or they can last for hours! Because of this, the user should be able to cancel these operations at which; sometimes because of a very slow internet connection, or maybe because of incorrect proxy settings (other conditions might occur too). Some (or maybe all) of these operations in PackageKit are not cancelable, and is a source of major frustration with package management system. Currently, usually the user will end up killing the PackageKit process to be able to continue his work (if he is lucky enough to know about killing the processes!).
A real example: I'm connected to a very slow internet connection using my mobile phone. For whatever reason, I decide to lookup a package information in PackageKit. I start PackageKit and write the package name and press the find button. PackageKit goes into the "Starting" status and remains in it. This lasts for a few minutes and I think that it is going to connect to a repository and download its information. As I know that it is almost impossible with my current connection, I want to cancel the operation, but there is no way to do it.
Then I close packagekit (gpk-application) and try using "yum -C info mypackage", but it says that PackageKit is still holding the lock. That's nonsense, I've closed the package kit window, so the search results are useless and I expect packageKit to release the lock immediately (or almost immediately) after I close the application. Finally, I end up killing packagekit daemon to be able to run my desired yum operation.
The same situation could happen if you are in a network which uses proxy to connect to internet and you've not setup proxy settings in your system.
IMHO, it is a very important bug since it delivers a very bad impression about the whole package management system (I've seen it a lot). So, please take it seriously.
Thanks a lot
(In reply to comment #0)
> IMHO, it is a very important bug since it delivers a very bad impression about
> the whole package management system (I've seen it a lot). So, please take it
Sure, I agree. It problem is you is an external process, and we try to sendit signals to make it quit. But if it ignores the signals, there isn't much we can do.
Well, actually that's a lie. We can use SIGKILL, but that has the tenancy to mess up your rpmdb. Which makes people kinda angry.
I would be interested to see the debug output. Could you do
(ensure yum is also not blocking)
/usr/libexec/packagekitd --backend=yum --disable-timer --verbose
and then try to start a transaction that 'wont' cancel.
Created attachment 38815 [details]
packagekitd log during a non-cancelable operation
Thanks a lot for your consideration.
(In reply to comment #1)
> Well, actually that's a lie. We can use SIGKILL, but that has the tenancy to
> mess up your rpmdb. Which makes people kinda angry.
I think it is reasonable to expect that a backend should be safely cancelable/kill-able! during a network operation (considering the above argument). If it doesn't, I think this is a bug in the backend. There is no reason for yum to touch rpmdb while it is downloading something IMHO.
(In reply to comment #2)
>TI:16:34:49 FI:pk-transaction.c FN:pk_transaction_allow_cancel_cb,435
> - emitting allow-cancel 0
This looks wrong. Setting up the search should be cancellable, and there's an explicit self.allow_cancel(True) in the code (ln 451)
I'll try to find the problem now.
Okay, yum, in all it's infinite wisdom, needs to download the packagelist repodata to get the list of enabled repos. I have no idea why it needs to do that.
Author: Richard Hughes <email@example.com>
Date: Mon Sep 20 16:40:31 2010 +0100
yum: for some reason yum needs to download the packagelists at init, so mark the download as cancellable. Fixes fd#30276
There's a new release planned in just over a week, and this fix will be in that release. Thanks.
I've found another bug in canceling which I'll report as a separate bug.
(In reply to comment #5)
> Okay, yum, in all it's infinite wisdom, needs to download the packagelist
> repodata to get the list of enabled repos. I have no idea why it needs to do
> commit da4e08f88e97c3663dc1a186b435af905ee25704
> Author: Richard Hughes <firstname.lastname@example.org>
> Date: Mon Sep 20 16:40:31 2010 +0100
> yum: for some reason yum needs to download the packagelists at init, so
> mark the download as cancellable. Fixes fd#30276
> There's a new release planned in just over a week, and this fix will be in that
> release. Thanks.
Today I say that the cancel button is disable when packagekit status is "Downloading file lists". Is this also solved by this fix?
(In reply to comment #7)
> Today I say that the cancel button is disable when packagekit status is
> "Downloading file lists". Is this also solved by this fix?
Great. Thanks again. :)