Hi, I am new to OpenSuse and I have a fresh install of OpenSuse 13.2 with all updates installed.
However, I am experiencing an unexpected behaviour of the update applet.
When all updates are installed and I click on the update icon and check for new updates it says “Uknown role type” and “Unknown state”.
The same is displayed when I click on the + sign beside individual updates.
Is this normal behaviour?
I’m having the same issue, even in 13.1
After the install of 13.2, I saw once or twice this application properly functioning.
Anyway, tough it would be nice to work, I only use it for security downloads. The rest I go with yast.
Also a newbie 
Yes, that’s a cosmetical problem. Just ignore it.
The same is displayed when I click on the + sign beside individual updates.
Is this normal behaviour?
This is a bug/limitation.
PackageKit shuts itself down after 15 seconds of inactivity to not block YaST/zypper.
But then Apper cannot display the details (that you get when clicking on ‘+’) any more. If you click on a ‘+’ it should work for another 15 seconds.
If it doesn’t any more “check for new updates”, it should work again then (for 15 seconds).
Workaround: change the ShutdownTimeout in /etc/PackageKit/PackageKit.conf to a higher value, or remove it completely to disable Shutdown at all. But you won’t be able to use YaST/zypper anymore then without manually killing packagekitd.
Thank you for the explanation. Now I get it.
Although it seems strange that they block each other, especially if they are only checking information about various packages.
Well, that’s a limitation in libzypp it seems:
https://bugzilla.suse.com/show_bug.cgi?id=899755
Work is underway to make them interact more nicely and not block each other unnecessarily. But I cannot tell you details about the current status or how long that will take.
Nothing that would be released as update for 13.2 at least I think.
Well blocking is needed because you do not want multiple (same) updates happening at the same time. So some basic file is locked to keep other programs from using it until the update is complete. Think about it do you want 2 different programs loading the same updates at the same time. 
On 2014-11-29 02:16, gogalthorp wrote:
>
> Well blocking is needed because you do not want multiple (same) updates
> happening at the same time. So some basic file is locked to keep other
> programs from using it until the update is complete.
Yes, but the point is, no blocking is really needed when all you are
doing is looking at packages and thinking. Only “writing” ops need block.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Hi,
This is probably off the topic.
I always turn off those update applets.
I check the updates using yast or visit
this forum to see the new update announcement
in the news forums.:).
This way I need not worry about those applets errors.
On Sat, 29 Nov 2014 01:16:01 GMT, gogalthorp
<gogalthorp@no-mx.forums.opensuse.org> wrote:
>
>Well blocking is needed because you do not want multiple (same) updates
>happening at the same time. So some basic file is locked to keep other
>programs from using it until the update is complete. Think about it do
>you want 2 different programs loading the same updates at the same time.
>:P
Very true. It also shares many of the same aspects and issues as shared
database update atomicity. See postgress, mysql and many others.
?-)
True, and at the moment too much is blocked.
I.e. you can’t use YaST/zypper if packagekitd is running without even doing anything.
But that’s no new problem, that was the case in earlier versions as well.
Hopefully this will be fixed in time for 13.3.
It’s more of a problem for “gnome-software” I think, this needs packagekitd running all the time AIUI.
On 2014-11-29 14:16, wolfi323 wrote:
>
> robin_listas;2679567 Wrote:
> True, and at the moment too much is blocked.
> I.e. you can’t use YaST/zypper if packagekitd is running without doing
> anything.
> But that’s no new problem, that was the case in earlier versions as
> well.
I know, it is an old problem. And it is not only with those applets.
For instance, when I have yast sw-single module running, thinking about
what to do, I may want to run an rpm query to find some thing - and it
refuses. A query! Not an install.
I have to exit YaST, on which I may already have marked files for
action, run the query, then start yast, remember my actions to re-select
them (no, telling yast to “save” instead tries to apply the actions, not
save them for later), then add new actions considering the query results
which I have now on a file.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I think the problem that used to come up with packagekit is that it did not quit is a reasonable time or at all frame thus blocked things . Now it quits too fast and we don’t get a really chance to view the remarks on installs via appr. (don’t know why they can t reconnect when a comment is asked to expand. Seems obvious to me I don’t always get a chance to look at the list in the first 15 seconds arrrgh ) In any case I have not run into the problem of packagekit blocking for several versions. Yes you can get a block if you try to run appr+yast+zypper but that should be by design to maintain data integrity.
On 2014-11-29 18:06, gogalthorp wrote:
>
> I think the problem that used to come up with packagekit is that it did
> not quit is a reasonable time or at all frame thus blocked things . Now
> it quits too fast and we don’t get a really chance to view the remarks
> on installs via appr. (don’t know why they can t reconnect when a
> comment is asked to expand. Seems obvious to me I don’t always get a
> chance to look at the list in the first 15 seconds arrrgh ) In any case
> I have not run into the problem of packagekit blocking for several
> versions. Yes you can get a block if you try to run appr+yast+zypper but
> that should be by design to maintain data integrity.
Rather a miss-design. Nobody thought that anybody would want read
access to the rpm database from two or more apps at the same time. This
is possible to do, but you have to design the database and tools for
that from the start. Not simple, but doable: multiuser databases do it
all the time.
It is write access which should block, not read access. Not queries.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, that makes perfect sense. Why both of them shouldn’t work if they only need read access?
Someone here suggested using only yast for updates when needed, however my Yast updater does not show any new update, whereas the applet shows dozens of them.
On 2014-11-30 15:16, pumrel wrote:
>
> Yes, that makes perfect sense. Why both of them shouldn’t work if they
> only need read access?
> Someone here suggested using only yast for updates when needed, however
> my Yast updater does not show any new update, whereas the applet shows
> dozens of them.
Yes, it does, but you have to know how.
This is for the QT flavour.
Select the view by repository type. Then select a repository, and on the
right hand panel with the rpm list, right click, all on this list (I’m
going from memory, wording might be different), then select “update if
newer”.
That is equivalent to a “zypper up”. If you select “update
unconditionally” then it is similar to a “dup”.
An alternative is to select the pseudo repo that displays all packages,
then update if newer. I prefer doing it repo by repo, though.
The advantage to zypper is that you can solve conflicts with the mouse,
and investigate a bit.
Also, you have to be careful on the packman repo, because sometimes they
go back in the version number of some packages, so the update doesn’t
happen. You have to browse the list watching for red packages, and use
the mouse to force the “update”, aka “degrade”.
Another operation is change the filter to display “unmaintained
packages” and possibly remove them.
On the GTK (Gnome) YaST flavour the operation would be different, and I
can not describe it. It is unfamiliar to me.
I prefer this procedure to using apper.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Not exactly.
“Update Unconditionally” will re-install the package even if there is no other version available, whereas “zypper dup” will not.
Also, you have to be careful on the packman repo, because sometimes they
go back in the version number of some packages, so the update doesn’t
happen. You have to browse the list watching for red packages, and use
the mouse to force the “update”, aka “degrade”.
“Update Unconditionally” will also do a downgrade if only a lower version/revision is available.
On 2014-11-30 19:26, wolfi323 wrote:
>
> robin_listas;2679850 Wrote:
>>
>> That is equivalent to a “zypper up”. If you select “update
>> unconditionally” then it is similar to a “dup”.
> Not exactly.
That’s why I said “similar” 
>> Also, you have to be careful on the packman repo, because sometimes they
>> go back in the version number of some packages, so the update doesn’t
>> happen. You have to browse the list watching for red packages, and use
>> the mouse to force the “update”, aka “degrade”.
> “Update Unconditionally” will also do a downgrade if only a lower
> version/revision is available.
True.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thank you very much for the info Although I must say that it could have been more straightforward.
On 2014-11-30 21:16, pumrel wrote:
>
> Thank you very much for the info Although I must say that it could
> have been more straightforward.
YaST development has stalled for some years. They have removed features
for lack of developers, so improving or adding features seems out of the
question, unless really needed…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On Sat, 29 Nov 2014 18:43:06 GMT, “Carlos E. R.”
<robin_listas@no-mx.forums.opensuse.org> wrote:
>On 2014-11-29 18:06, gogalthorp wrote:
>>
>> I think the problem that used to come up with packagekit is that it did
>> not quit is a reasonable time or at all frame thus blocked things . Now
>> it quits too fast and we don’t get a really chance to view the remarks
>> on installs via appr. (don’t know why they can t reconnect when a
>> comment is asked to expand. Seems obvious to me I don’t always get a
>> chance to look at the list in the first 15 seconds arrrgh ) In any case
>> I have not run into the problem of packagekit blocking for several
>> versions. Yes you can get a block if you try to run appr+yast+zypper but
>> that should be by design to maintain data integrity.
>
>Rather a miss-design. Nobody thought that anybody would want read
>access to the rpm database from two or more apps at the same time. This
>is possible to do, but you have to design the database and tools for
>that from the start. Not simple, but doable: multiuser databases do it
>all the time.
>
>It is write access which should block, not read access. Not queries.
+2 Hugely agreed.
?-)