* Carlos E. R. [11-01-12 07:40]:

On 2012-11-01 11:35, Sven Burmeister wrote:

...

Maybe it helps to define what is needed in order to find a tool. And if there is none to understand what to focus on in order to improve the situation with the apps available.

- not blocking zypper - maintained graphical front-end (notifier and patch list etc.) - maintained back-end - installing patches/updates without root password - ability to set permissions per user/action regarding package management

With ability to provide a restricting list of users that can use it and get notification. Any other user, the applet should not even run.

...

- ability to check for patches only or patches plus updates from buildservice repos (even better if one can define which repos to check)

And modifying that list should not alter the list of repos of yast/zypper. Ie, the list of repos I want to keep an eye on updates may not be the same as the list of all repos configured.

++ Re: restricting users (special case) Ability to view but no permissions to act -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-01 19:33, Patrick Shanahan wrote:

* Carlos E. R. <> [11-01-12 07:40]:

++

Re: restricting users (special case) Ability to view but no permissions to act

To view if they start it manually, ok, but should not start automatically for them. Two reasons: one, they ask and bother the admin (what is that update I see in...? Two, they are hindered by activity from the applet. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCS1G4ACgkQja8UbcUWM1zZagD+NAOLlJ3ADL/i6WLbY6Geqq2q MGRHfOFlVg/FIz8stjQA/08mGoXuWb3El7lyVUSmvks1XAtZ5tawfowNRqtqrf1r =izUW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 01 November 2012 11:35:14 Sven Burmeister wrote:

Am Donnerstag, 1. November 2012, 11:14:59 schrieb Raymond Wooninck:

...

So the question is will we keep PackageKit in our openSUSE distro or not ? If yes, then the zypp/YaST community should have a look at the latest version and make the zypp backend build and work again. If not, do we have alternatives that we can offer to the users as a small systray utility that notifies them when updates are available ?

Maybe it helps to define what is needed in order to find a tool. And if there is none to understand what to focus on in order to improve the situation with the apps available.

- not blocking zypper - maintained graphical front-end (notifier and patch list etc.) - maintained back-end - installing patches/updates without root password - ability to set permissions per user/action regarding package management - ability to check for patches only or patches plus updates from buildservice repos (even better if one can define which repos to check)

Note that PackageKit is also supported by a number of upstream applications to install packages like the multimedia stuff in audioplayers. Also, it forms the base of a number of appstore-like technologies which I personally would love to have in openSUSE as the YaST GTK and Qt interfaces are both quite terrible to use if you're not a sysadmin-level user. All in all, the problem lies in the libzypp backend, and Michael Andres just said he's working on it but as you can see in the mail he linked to it will take a while as he has to re-work quite a bit in zypper. See http://lists.opensuse.org/zypp-devel/2012-08/msg00010.html This means that zypper will get some improvements due to the requirements of PackageKit - I'd love to see zypper not block a search or info when I am installing stuff (!!!) so I don't mind that much. Now if any of you is interested in helping out, I'm sure help is welcome... Hugs, Jos

Sven

On Thu, Nov 01, 2012 at 01:44:19PM +0100, Guido Berhoerster wrote:

* Raymond Wooninck [2012-11-01 11:18]:

...

make the zypp backend build and work again. If not, do we have alternatives that we can offer to the users as a small systray utility that notifies them when updates are available ?

It wouldn't tkae too much effort to swap out the PackageKit backend in pk-update-icon with a zypper-based one, in fact I do already have a parser for zyppers XML output from some experiments last year. It uses GTK+ but the UI consists only of a tray icon and notification bubble which would open "yast2 online_update" when activated so it should not look alien in KDE. So if there's a rough consensus that we want to go with a minimal notifier and update via YaST's online_update module I could put something together.

We actually had a zypper based KDE applet some years ago. But I still think we should work with upstream PackageKit to get bugs fixed and our support in. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 01 November 2012 13:44:19 Guido Berhoerster wrote:

It wouldn't tkae too much effort to swap out the PackageKit backend in pk-update-icon with a zypper-based one, in fact I do already have a parser for zyppers XML output from some experiments last year. It uses GTK+ but the UI consists only of a tray icon and notification bubble which would open "yast2 online_update" when activated so it should not look alien in KDE. So if there's a rough consensus that we want to go with a minimal notifier and update via YaST's online_update module I could put something together.

It is not only a matter of the effort required to build something small to perform this task. I have no doubt that you are able to deliver what you indicated, but are you willing to maintain this piece of software for the rest of it's lifecycle ? Because if we introduce another piece of software which will not be supported in the future, then we end up exactly at the same place as we are now. I guess that we should also be looking at the position we are now. Recently this mailinglist has been flooded with complaints with regards to the tools openSUSE is using for booting, repairtools, etc. There were even some indications that other distributions have much better tools, etc. But as soon as it comes to move to a more distro-independent solution, people are coming up that we can create little programs around the tools we have. There is nothing wrong with this, but is this the position we want to be in ?? Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

The following is worth what you paid for it: I've been a loyal SuSE (and, later, openSUSE) user since 9.3, and I've been doing the whole Linux thing since 1994. I've seen package management interfaces come and go. For a long time, smart (smartpm) was my preferred choice, as it *vastly* outperformed rug and others (incl. the early releases of zypper). Then zypper finally stabilized and things were pretty good. Then came along PackageKit. From a design perspective, it seemed to be the way of the future, but from a practical perspective it just didn't live up. Release after release there were bugs (and there still are), it was *slow* and resource hungry (and still is), not as capable (still true), and now the version in use is out of date. I got used to removing packagekit* as the very first step after installation, and relying instead on zypper (manual and cron). Now we are at 12.2 and packagekit *still* doesn't work quite right. Please consider: *after* 12.2 was released, 'pkcon' still didn't work on half of the machines I've got (since resolved) *after* 12.2 was released, packagekit still had architecture problems (installing i586 on x86_64) We *still* don't have an especially informative packagekit interface. The feedback on download progress is useless, overall progress isn't present, and by recent discussion there are still significant issues with threading, requiring *at least* one more distro release to resolve, perhaps more. Choosing on machine that still has packagekit installed, I just ran "dmesg | grep segfault". Care to guess what I found? PK-Backend. I have that machine set to auto-update and auto-install by way of packagekit, but it doesn't work sometimes. Can I tell why? No. Even when it *does* work it seems to chew up CPU and take a *really* long time to do... anything. It seems to me that - while packagekit's design and goals are laudable in and of themselves, at some point you have to consider the practical effects of these decisions on your users. The reputation of a flakey, troublesome, irritating software update interface is well-deserved. Is it better than it was? Yes. Does it work well? Not for everybody. Not for me. And - this is a critical question - am I better off *now* than I was 5 years ago (in this respect)? Not really. zypper works. Today. I am not suggesting that all work on packagekit be abandoned, but from a purely pragmatic perspective, just exactly how many developer hours would it take to a) resolve the packagekit <-> libzypp issues b) update to the more recent packagekit backend c) *stay in sync* with upstream packagekit b) maintain the packagekit stack until such time as doing so is no longer necessary (a better alternative - whatever that may be - exists) as compared to a) provide a notification interface that interfaces with zypper/yast2 that identifies when updates are ready b) maintain that software until such time as doing so is no longer necessary (a better alternative - whatever that may be - exists) That's my rant and I'm sticking to it. Please do not take offense, for none was intended. Instead, please take a step back and consider things from the perspective of a user that has not had a problem-free packagekit install *ever*. -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 1. November 2012, 09:32:43 schrieb Jon Nelson:

zypper works. Today. I am not suggesting that all work on packagekit be abandoned, but from a purely pragmatic perspective, just exactly how many developer hours would it take to a) resolve the packagekit <-> libzypp issues b) update to the more recent packagekit backend c) *stay in sync* with upstream packagekit b) maintain the packagekit stack until such time as doing so is no longer necessary (a better alternative - whatever that may be - exists)

as compared to a) provide a notification interface that interfaces with zypper/yast2 that identifies when updates are ready b) maintain that software until such time as doing so is no longer necessary (a better alternative - whatever that may be - exists)

c) can install updates without root password d) can have different permissions regarding installing/updating depending on the user e) allows to choose whether to check for patches only or all available updates f) does not end-up like e.g. kupdateapplet (which basically was what you describe, i.e. nothing but a notifier) Having just a notification icon is going backwards 5 years and not improving the situation IMO, leaving aside the comparison to other distros/OSs. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-01 17:23, Jon Nelson wrote:

You raise some very good points! However, please find my comments inline, below:

On Thu, Nov 1, 2012 at 10:07 AM, Sven Burmeister <> wrote:

...

c) can install updates without root password

sudo permissions can fix (c)

But this needs an administrator to set it up first. Not very nice for people that admin their own machines. How the current tool handles this now is easier on the end user. And doing this at install needs configuring sudo entirely, which is... well, not that simple. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCSvMYACgkQja8UbcUWM1zmrAD/eLCPlEg64Iyy7Cc9gqvpSzdc 32J5m3GlEbdMBjqOQ5sA/33+l58BS3we7yAQljeoVZLDXAbnW1pANCqrD63RDZT0 =Rhwl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-01 19:39, Guido Berhoerster wrote:

* Carlos E. R. <> [2012-11-01 19:18]:

Nobody is considering to write a new package/update manager, this thread is about either fixing PK's zypper backend or instead using a small notifier applet instead of the PK-based ones.

Right. I vote for fixing, and if possible, improving.

We already have both YaST modules and the PK frontends for installing packages and applying updates which in combination with PolicyKit can do all of the stuff requested above.

There is no yast module for PK :-( - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCS1P0ACgkQja8UbcUWM1yPjAD+LpDnWmiLNepXZCe9rWAQb0U5 RpHbULUAY1HESNssXe4A/jqRkDJzNLTatVZIZjERZjqI3rP1a9kOSYqy1C2EoiY7 =U7KQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org