[opensuse-kde] QA testing team plan.
I think in a previous thread we identified some issues, and some possible solutions. I think to help assure the quality of our distro we need to create a QA team, with a good structure. One of the issues will be having strong centralized communication. I believe I can provide an excellent tool for this, as long as nobody is opposed to using an outside tool. 1. Establish QA team and resources 2. Divide the team into units 1. Assign area heads based on speciality. 2. Divide KDE testing into logical blocks of applications, such as plasma team, PIM team, etc. 3. Establish triaging guidelines and methodology. 1. Looks like the wiki has good guidelines on this 2. Check and compile lists from Bugzilla to create test cases 4. Efficient testing 1. Assign testing tasks and blocks to team members (self assigned or team sublead assigned is fine) 2. Track tasks, and keep notes. 1. The tool I have in mind and have access to is supremely suited to this. 5. Report findings 1. File new bug reports in the case of a bug being SOLVED, and flag the old possibly associated bugs with the new report. Check upstream for related reports. 2. Compile task list of outstanding bug findings, and check with upstream to see if problem is known or patched. 1. If the bug is unknown, file a new report with KDE 2. If the bug is patched, add to list of fixes that need to be applied. I think that about covers it. Queue brainstorm! -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sun, Jan 8, 2012 at 11:45 AM, Roger Luedecke <roger.luedecke@gmail.com> wrote:
I think in a previous thread we identified some issues, and some possible solutions.
I think to help assure the quality of our distro we need to create a QA team, with a good structure. One of the issues will be having strong centralized communication. I believe I can provide an excellent tool for this, as long as nobody is opposed to using an outside tool.
1. Establish QA team and resources 2. Divide the team into units 1. Assign area heads based on speciality. 2. Divide KDE testing into logical blocks of applications, such as plasma team, PIM team, etc. 3. Establish triaging guidelines and methodology. 1. Looks like the wiki has good guidelines on this 2. Check and compile lists from Bugzilla to create test cases 4. Efficient testing 1. Assign testing tasks and blocks to team members (self assigned or team sublead assigned is fine) 2. Track tasks, and keep notes. 1. The tool I have in mind and have access to is supremely suited to this. 5. Report findings 1. File new bug reports in the case of a bug being SOLVED, and flag the old possibly associated bugs with the new report. Check upstream for related reports. 2. Compile task list of outstanding bug findings, and check with upstream to see if problem is known or patched. 1. If the bug is unknown, file a new report with KDE 2. If the bug is patched, add to list of fixes that need to be applied.
I think that about covers it. Queue brainstorm!
I agree with what some others said about keeping a single list of patches against KDE, when they were added, and what they do. There apparently are not that many, so it shouldn't be too hard. These are supposed to be in the .spec file, but many are not, and having them in a central place would probably make it easier. This isn't only for debugging, but just for general maintenance, since just looking at the spec files and patches it is not always clear what they do. Another thing I would suggest is a list of official keywords that can be added to bugs to make it easier to keep track of what specifically they are related to. So bluetooth bugs might be assigned to KDE, but could have a bluetooth keyword. Bugs that maybe hardware-specific could have a hardware-specific keyword. The name of the application affected should probably always be included as a keyword. Making good use of keywords should make it a lot easier to keep track of bugs. Another thing I was thinking about, and may not be a good idea at all, would be to have patches in spec file divided into 4 categories: openSUSE-specific bugfixes, openSUSE-specific features, backported bugfixes, and backported features. Each of these categories would have a project-wide build flag associated with it, so that they can be disabled as a group all at once for all packages in a project. This would make it easy for someone to branch a problematic package into another repo, disable, say, all backported features, and then check to see if that fixes the problem. This may be infeasible in practice, though. While we are at it may also be good for the QA team to do a comprehensive revue of all patches to see which ones might not be good, which ones are obsolete, which ones should be pushed upstream, etc. If this is an initiative for all of openSUSE, might this serve as an opportunity to transition to an openSUSE-specific bugzilla? -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sun, 8 Jan 2012 11:45, Roger Luedecke <roger.luedecke@...> wrote:
I think in a previous thread we identified some issues, and some possible solutions.
I think to help assure the quality of our distro we need to create a QA team, with a good structure. One of the issues will be having strong centralized communication. I believe I can provide an excellent tool for this, as long as nobody is opposed to using an outside tool.
<snip> Addenum to think of: If one looks at what "polkit" does, and just HOW it violates FHS (modifications are done in /usr/..., /var/... is ignored/lower prio) it's no wonder that apps/services that build on this fuctionality (package-kit) fail to work properly. Food for thought: - How do other distros handle the updates? - Which way is the most painless? In earlier versions of openSUSE there was a wrapper called "you" for "yast2 online_update", this wrapper could be made 'priviledged' by simply addding a line to /etc/sudoers. Then add a .desktop file for "you" and you have a working updater for everybody, even with gui! To reintroduce this would stop the "need" for polkit. At least for updates. And this woud use YAST not any other "not-working-right-puppet". Sorry for the work you put into the "update-applets", but without reliable backends (hello polkit!) they all fall short. Should we (devs, packagers, users) make noise to remove polkit at all from 12.2 ? (Fix upstream fully or remove!) Whitout the hassle of polkit the REAL trouble inside package-kit would be ripe for debugging. - Yamaban. PS: Sorry for the rant, but the polkit hassle is just to much to bear. The memory used by polkit and consorts can be used better elsewhere. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sun, 8 Jan 2012 11:45, Roger Luedecke <roger.luedecke@...> wrote:
I think in a previous thread we identified some issues, and some possible solutions.
I think to help assure the quality of our distro we need to create a QA team, with a good structure. One of the issues will be having strong centralized communication. I believe I can provide an excellent tool for this, as long as nobody is opposed to using an outside tool.
<snip>
Addenum to think of:
If one looks at what "polkit" does, and just HOW it violates FHS (modifications are done in /usr/..., /var/... is ignored/lower prio) it's no wonder that apps/services that build on this fuctionality (package-kit) fail to work properly.
Food for thought: - How do other distros handle the updates? - Which way is the most painless?
In earlier versions of openSUSE there was a wrapper called "you" for "yast2 online_update", this wrapper could be made 'priviledged' by simply addding a line to /etc/sudoers.
Then add a .desktop file for "you" and you have a working updater for everybody, even with gui!
To reintroduce this would stop the "need" for polkit. At least for updates. And this woud use YAST not any other "not-working-right-puppet".
Sorry for the work you put into the "update-applets", but without reliable backends (hello polkit!) they all fall short.
Should we (devs, packagers, users) make noise to remove polkit at all from 12.2 ? (Fix upstream fully or remove!)
Whitout the hassle of polkit the REAL trouble inside package-kit would be ripe for debugging.
- Yamaban.
PS: Sorry for the rant, but the polkit hassle is just to much to bear. The memory used by polkit and consorts can be used better elsewhere. I forked this discussion since I didn't want the thread hijacked. I
On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote: think your scheme is very reasonable. However, frankly policykit has rarely gotten in my way or caused trouble... only in KDE, and mostly with Apper. Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things. What I mean by the last statement is since we often have different versions of a piece of software in different repos, and many of us have those repos, Apper fails to show why there are duplicate packages and doesn't give the versions. This is sloppy at best, potentially dangerous at worst. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
* Roger Luedecke <roger.luedecke@gmail.com> [01-09-12 05:37]:
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things.
Instead of ranting about it, it appears you *really* don't like it, why don't you remove it. I disliked it and removed it and am no longer concerned about it. I don't have to use it. I don't recall if I had dependencies to adjust but: zypper -v rm apper removes apper and tells me which dependencies must also be removed. dependencies were/are: apper libpackagekit-glib2-14 libpackagekit-qt2-2 PackageKit PackageKit-branding-openSUSE I do not miss any of them. Updates are simple via: zypper -v up -- (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-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon 09 Jan 2012 08:54:38 AM EST, Patrick Shanahan wrote:
* Roger Luedecke <roger.luedecke@gmail.com> [01-09-12 05:37]:
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things.
Instead of ranting about it, it appears you *really* don't like it, why don't you remove it. I disliked it and removed it and am no longer concerned about it. I don't have to use it. I don't recall if I had dependencies to adjust but: zypper -v rm apper removes apper and tells me which dependencies must also be removed.
dependencies were/are: apper libpackagekit-glib2-14 libpackagekit-qt2-2 PackageKit PackageKit-branding-openSUSE
I do not miss any of them. Updates are simple via: zypper -v up
I read last year that someone is working on a Yast Updater Applet. Can anyone confirms this? Cheers! Roman ------------------------------------------------ Discover it! Enjoy it! Share it! openSUSE Linux ------------------------------------------------ http://counter.li.org #179293 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon 09 Jan 2012 08:54:38 AM EST, Patrick Shanahan wrote:
* Roger Luedecke <roger.luedecke@gmail.com> [01-09-12 05:37]:
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things.
Instead of ranting about it, it appears you *really* don't like it, why don't you remove it. I disliked it and removed it and am no longer concerned about it. I don't have to use it. I don't recall if I had dependencies to adjust but: zypper -v rm apper removes apper and tells me which dependencies must also be removed.
dependencies were/are: apper libpackagekit-glib2-14 libpackagekit-qt2-2 PackageKit PackageKit-branding-openSUSE
I do not miss any of them. Updates are simple via: zypper -v up
I read last year that someone is working on a Yast Updater Applet.
Can anyone confirms this?
Cheers!
Roman ------------------------------------------------ Discover it! Enjoy it! Share it! openSUSE Linux ------------------------------------------------ http://counter.li.org #179293 I think SLED uses something like that, instead of packagekit but I don't recall as I haven't used SLED in a while and only briefly in the first
On Mon, 2012-01-09 at 11:47 -0500, Roman Bysh wrote: place. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
* Roger Luedecke <roger.luedecke@gmail.com> [01-09-12 05:37]:
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things.
Instead of ranting about it, it appears you *really* don't like it, why don't you remove it. I disliked it and removed it and am no longer concerned about it. I don't have to use it. I don't recall if I had dependencies to adjust but: zypper -v rm apper removes apper and tells me which dependencies must also be removed.
dependencies were/are: apper libpackagekit-glib2-14 libpackagekit-qt2-2 PackageKit PackageKit-branding-openSUSE
I do not miss any of them. Updates are simple via: zypper -v up
-- (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 When it stopped working properly, I did remove it again. The point isn't to rant because I don't like it, on the contrary I'd like it fine if it worked consistently. But rather, it has been broken for such a long time
On Mon, 2012-01-09 at 08:54 -0500, Patrick Shanahan wrote: that it seems overdue to just be rid of it. Heck, I'd even be behind just using the updater from Gnome which does work nicely. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon, 9 Jan 2012 11:37, Roger Luedecke <roger.luedecke@...> wrote:
On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote: <snip>
PS: Sorry for the rant, but the polkit hassle is just to much to bear. The memory used by polkit and consorts can be used better elsewhere.
I forked this discussion since I didn't want the thread hijacked. I think your scheme is very reasonable. However, frankly policykit has rarely gotten in my way or caused trouble... only in KDE, and mostly with Apper.
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things. What I mean by the last statement is since we often have different versions of a piece of software in different repos, and many of us have those repos, Apper fails to show why there are duplicate packages and doesn't give the versions. This is sloppy at best, potentially dangerous at worst.
Sorry, thread-jacking wasn't my intention. More laying the blame where it belongs, and a proposal of a workaround. On Apper's failings, I agree with you, but to be cautious: What info can apper get from the packagekit backend, all - incluing the different repos, repo-priorites, and depenencies? If yes, then it's appers fault, and sloppy programming. If no, then packagekit should be held responsible. As I said sorry for all the work that's going down the drain, but: "No Work - No Cookie" The already existing and identified troubles inside packagekit are many, and no real drive to solve them upstream could be found by me. So before we bark at the moon: - If we drop polkit, packagekit, and those packages that can not life without those, would OSS 12.2 be better OSS 12.1 than now? - What are doing the other distros to update their packages? * RedHat / Fedora / Centos : Yum and ??? * Ubuntu / Debian : deb and ??? * Mandrivia : ??? and ??? * Arch: ??? and ??? * openSUSE and SUSE : Yast and ??? - What the hell is used under Gnome on OSS 12.1 ? ( Sorry not on my 12.1 atm. ) - Let's get ugly but working, small, and fast: a TK/Tcl gui for zypper. - Yamaban, who says thanks for all the work you guys and gals do. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon, Jan 9, 2012 at 6:02 PM, Yamaban <foerster@lisas.de> wrote:
On Mon, 9 Jan 2012 11:37, Roger Luedecke <roger.luedecke@...> wrote:
On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote:
<snip>
PS: Sorry for the rant, but the polkit hassle is just to much to bear. The memory used by polkit and consorts can be used better elsewhere.
I forked this discussion since I didn't want the thread hijacked. I think your scheme is very reasonable. However, frankly policykit has rarely gotten in my way or caused trouble... only in KDE, and mostly with Apper.
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things. What I mean by the last statement is since we often have different versions of a piece of software in different repos, and many of us have those repos, Apper fails to show why there are duplicate packages and doesn't give the versions. This is sloppy at best, potentially dangerous at worst.
Sorry, thread-jacking wasn't my intention. More laying the blame where it belongs, and a proposal of a workaround.
On Apper's failings, I agree with you, but to be cautious: What info can apper get from the packagekit backend, all - incluing the different repos, repo-priorites, and depenencies?
If yes, then it's appers fault, and sloppy programming. If no, then packagekit should be held responsible.
It may also be the fault of the zypper packagekit backend, in which case it is the responsibility of the openSUSE developers who made the backend. Most of what I have been hearing indicates that this is, in fact, the primary culprit, although I have no firsthand knowledge to that effect. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon, 9 Jan 2012 11:37, Roger Luedecke <roger.luedecke@...> wrote:
On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote: <snip>
PS: Sorry for the rant, but the polkit hassle is just to much to bear. The memory used by polkit and consorts can be used better elsewhere.
I forked this discussion since I didn't want the thread hijacked. I think your scheme is very reasonable. However, frankly policykit has rarely gotten in my way or caused trouble... only in KDE, and mostly with Apper.
Honestly, KPackageKit/Apper has been a thorn in our side long enough. I really haven't much hope of getting it settled. Plus, it is simply overkill for simply doing updates. And as a package management tool, it is inadequate for the way we do things. What I mean by the last statement is since we often have different versions of a piece of software in different repos, and many of us have those repos, Apper fails to show why there are duplicate packages and doesn't give the versions. This is sloppy at best, potentially dangerous at worst.
Sorry, thread-jacking wasn't my intention. More laying the blame where it belongs, and a proposal of a workaround. Understood, but it was a very different topic then a QA team.
On Apper's failings, I agree with you, but to be cautious: What info can apper get from the packagekit backend, all - incluing the different repos, repo-priorites, and depenencies? That is a good question.
If yes, then it's appers fault, and sloppy programming. If no, then packagekit should be held responsible. Considering these issues don't crop up with the Gnome updater and such, I should imagine it is Apper. Though the Gnome updater would seem to not understand when something is locked, and bumps me back to YaST to resolve the issue. This seems to be a packagekit issue more likely.
As I said sorry for all the work that's going down the drain, but: "No Work - No Cookie"
The already existing and identified troubles inside packagekit are many, and no real drive to solve them upstream could be found by me.
So before we bark at the moon:
- If we drop polkit, packagekit, and those packages that can not life without those, would OSS 12.2 be better OSS 12.1 than now? Why would we want to drop policykit?
- What are doing the other distros to update their packages? * RedHat / Fedora / Centos : Yum and ??? KDE version uses KpackageKit last I saw, which works fine for them. * Ubuntu / Debian : deb and ??? Ubuntu uses packagekit for updater, and synaptic/ Ubuntu Software Manager for general package management. * Mandrivia : ??? and ??? I think they use drakx for updates, but I'm not sure since I have had massive problems with running Mandriva. * Arch: ??? and ??? * openSUSE and SUSE : Yast and ???
- What the hell is used under Gnome on OSS 12.1 ? ( Sorry not on my 12.1 atm. )
- Let's get ugly but working, small, and fast: a TK/Tcl gui for zypper. Qt should be fine too. Heck, we could probably get away with a
On Mon, 2012-01-09 at 18:02 +0100, Yamaban wrote: privileged daemon that runs a check via zypper or w/e and then would pass its privileges to the YaST Online Updater.
- Yamaban, who says thanks for all the work you guys and gals do.
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon, 9 Jan 2012 23:21, Roger Luedecke <roger.luedecke@...> wrote: > On Mon, 2012-01-09 at 18:02 +0100, Yamaban wrote: >> On Mon, 9 Jan 2012 11:37, Roger Luedecke <roger.luedecke@...> wrote: >>> On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote: >> <snip> >> If yes, then it's appers fault, and sloppy programming. >> If no, then packagekit should be held responsible. > Considering these issues don't crop up with the Gnome updater and such, > I should imagine it is Apper. Though the Gnome updater would seem to not > understand when something is locked, and bumps me back to YaST to > resolve the issue. This seems to be a packagekit issue more likely. >> - If we drop polkit, packagekit, and those packages that can not >> life without those, would OSS 12.2 be better OSS 12.1 than now? > Why would we want to drop policykit? To quote a earlier message: "polkit violates the FHS" A easy test is to put /usr on a seperate partition and mount /usr readonly. Happy using polkit and applying your changes then. ATM polkit ignores any changes in /var if there's a corresponding rule in /usr. Recommendation: rewrite of the rule selection and change part. Without these changes: drop hard, and drop fast. You do not drive a car with a failing brakesystem, or do you? Polkit is a part of the security system, no failure allowed. >> - What are doing the other distros to update their packages? >> * RedHat / Fedora / Centos : Yum and ??? > KDE version uses KpackageKit last I saw, which works fine for them. - What does KpackageKit on Fedora different, than the one on OSS The backend, right? - How does Fedora it, calling yum or selfmade in KPK? >> * Ubuntu / Debian : deb and ??? > Ubuntu uses packagekit for updater, and synaptic/ Ubuntu Software > Manager for general package management. - See above: Backend to deb, or selfmade in packagekit? >> * Mandrivia : ??? and ??? > I think they use drakx for updates, but I'm not sure since I have had > massive problems with running Mandriva. - Thanks for the info. >> - Let's get ugly but working, small, and fast: a TK/Tcl gui for zypper. > Qt should be fine too. Heck, we could probably get away with a > privileged daemon that runs a check via zypper or w/e and then would > pass its privileges to the YaST Online Updater. The idea behind TK/Tcl was not dependeny on gnome/gtk and/or kde/qt. On the other hand, YaST does a good handling on gtk/qt/ncurses A not-an-applet, but a program which resides in the system-tray as an icon and works, no matter of qt / gtk / whatever would be the best, if not most harmonious solution. Ensurance of clean operation first, gimiks and style later. And please no updater should ever have any dependency on plasma, never! (let the sleeping dogs lay, no sense in tickling the sleeping dragons.) - Yamaban PS: what steps would one have to go to use the gnome-updater in KDE, and what are the failures of gnome-updater? (Removing the KDE part from the updater troubles) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mon, 2012-01-09 at 23:53 +0100, Yamaban wrote: > On Mon, 9 Jan 2012 23:21, Roger Luedecke <roger.luedecke@...> wrote: > > > On Mon, 2012-01-09 at 18:02 +0100, Yamaban wrote: > >> On Mon, 9 Jan 2012 11:37, Roger Luedecke <roger.luedecke@...> wrote: > >>> On Mon, 2012-01-09 at 04:50 +0100, Yamaban wrote: > >> <snip> > >> If yes, then it's appers fault, and sloppy programming. > >> If no, then packagekit should be held responsible. > > Considering these issues don't crop up with the Gnome updater and such, > > I should imagine it is Apper. Though the Gnome updater would seem to not > > understand when something is locked, and bumps me back to YaST to > > resolve the issue. This seems to be a packagekit issue more likely. > > >> - If we drop polkit, packagekit, and those packages that can not > >> life without those, would OSS 12.2 be better OSS 12.1 than now? > > Why would we want to drop policykit? > > To quote a earlier message: "polkit violates the FHS" > A easy test is to put /usr on a seperate partition and mount /usr > readonly. > > Happy using polkit and applying your changes then. > > ATM polkit ignores any changes in /var if there's a corresponding > rule in /usr. > > Recommendation: rewrite of the rule selection and change part. > Without these changes: drop hard, and drop fast. > > You do not drive a car with a failing brakesystem, or do you? > Polkit is a part of the security system, no failure allowed. > > > >> - What are doing the other distros to update their packages? > >> * RedHat / Fedora / Centos : Yum and ??? > > KDE version uses KpackageKit last I saw, which works fine for them. > > - What does KpackageKit on Fedora different, than the one on OSS > The backend, right? - How does Fedora it, calling yum or selfmade in KPK? > > >> * Ubuntu / Debian : deb and ??? > > Ubuntu uses packagekit for updater, and synaptic/ Ubuntu Software > > Manager for general package management. > - See above: Backend to deb, or selfmade in packagekit? > > > >> * Mandrivia : ??? and ??? > > I think they use drakx for updates, but I'm not sure since I have had > > massive problems with running Mandriva. > - Thanks for the info. > > >> - Let's get ugly but working, small, and fast: a TK/Tcl gui for zypper. > > Qt should be fine too. Heck, we could probably get away with a > > privileged daemon that runs a check via zypper or w/e and then would > > pass its privileges to the YaST Online Updater. > > The idea behind TK/Tcl was not dependeny on gnome/gtk and/or kde/qt. > On the other hand, YaST does a good handling on gtk/qt/ncurses That makes sense, though updating in Gnome works fine. But this makes great sense if indeed we were to drop polkit. > > A not-an-applet, but a program which resides in the system-tray as an icon > and works, no matter of qt / gtk / whatever would be the best, if not most > harmonious solution. > > Ensurance of clean operation first, gimiks and style later. Emphatically agreed. > > And please no updater should ever have any dependency on plasma, never! > (let the sleeping dogs lay, no sense in tickling the sleeping dragons.) Agreed. I think Plasma is still too messy. > > - Yamaban > > PS: what steps would one have to go to use the gnome-updater in KDE, > and what are the failures of gnome-updater? > (Removing the KDE part from the updater troubles) I have never seen the Gnome updater fail outright, though it hiccups on an update where a package is locked, but at least tells you the issue and drops you into the YaST updater. Thus, I say it works well. I imagine using the Gnome updater would be no more involved than the using of the Gnome network manager in KDE. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
KUpdate Applet with zypp backend started to work pretty well, and used to provide better feedback about the updates to the user than Kpackagekit, and then suddently was replaced by a broken Kpackagekit, I still don't understand why. Yast Online Update is also a good tool. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (6)
-
Patrick Shanahan -
Rafael Belmonte -
Roger Luedecke -
Roman Bysh -
todd rme -
Yamaban