On Tue, 2008-12-09 at 01:25 +0100, Robert Scheck wrote: > PackageKit is resizing windows during installation or updating > of packages; it's resizing and thus hopping the window if I e.g. select a > package or if I click around inside of the application. That's something, > which proves, that there is no usability for end users yet. If you file a bug I'll fix it. > And the > related GNOME tray utility is also slow and usually is behind the current > action...that's packagekitd, yes? gnome-packagekit if you are on GNOME, kpackagekit if you are on KDE. Did you file a bug about it being slow? It's very fast on my system. > One of these utilities also often blocks > the usage of yum with saying, that another application currently holds the > lock. Why are we locking something when not performing a writing action on > the RPM database? That seems to be mis-engineered very well. It only locks the database when there is an active yum transaction running. I can assure you you don't want two things playing with the rpmdb at once. > Independent of that, PackageKit is somehow slow Not a very useful comment. > has issues that it doesn't understand > always where it is or whether an action is already completed. Oh and it > kills my Firefox nicely during package updating, well-well done. "kills my firefox" also doesn't seem a great error report. It might help lower your blood pressure if you filed bugs in bugzilla. Sounds like a bug in firefox to me. > When talking about PackageKit, DBUS is another issue. The recent DBUS pkg > update broke PackageKit stuff - thanks to our cool QA. And clever as we > are, we did not revoke the update and we also did not push a fixed package > really immediately out after to solve this. > I know, that many of the > desktop people actually love DBUS, but it is horrible stuff, which can > break down much things with lacking QA like in this case. The DBus update broke applications not conforming 100% to the spec. Unfortunately this update was pushed directly into stable (not updates-testing) and so nobody got a chance to test it. We're all fixing applications as fast as we can. > Did you desktop > people ever think about, that DBUS is not the perfect choice for a server > system and Fedora is some kind of preview of RHEL? DBus works very well on a server. > Yes, Fedora is not the > playground of Red Hat, but on the other hand, Fedora is - why else is Red > Hat putting efforts into Fedora if they wouldn't benefit? I really can only > hope here, that Red Hat removes much of the DBUS breakage and dumbness for > the next RHEL release and that less DBUS linked packages are making it into > there... Maybe you should apply for a job at Red Hat, and then you can give some opinions on what Red Hat chooses to do with RHEL. I'll tell you a little secret: RHEL 6 is still going to include DBus. > And as we're cool, we need a daemon for everything: packagekitd, dbusd, hal > daemon, mcstransd, setroubleshootd, yum-updatesd - yay. And nearly every of > this daemons is written in the memory consuming python packagekitd, dbus and hal are written in C. > I'm aware, > that python is the Red Hat internal defacto default Erm, unless I missed the memo, there is no "Red Hat internal defacto default"... > and that scripting is > much more faster rather coding low-level C. But lets waste ressources as > e.g. kerneloops daemon does which always consumes a bit of CPU and thus not > increases the consuming of energy in a positive way. But hey, let's create > another daemon to monitor where we're wasting and leaking memory... I don't think this is a reasoned argument, sorry. To be honest, I think you need to write much shorter, to the point emails. Ranting doesn't have much affect on anything, whilst filing bugs and getting involved upstream does. Richard. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
