Petrus de Calguarium wrote:
> 1. packagekit: I did not particularly like the one version a while back
> that relied on smart. It never worked.
That was KPackage, not KPackageKit. Completely different program.
> What I find missing in all of these package managers is the ability to
> explore the repositories.
Well, KPackageKit allows you to do searches. What's missing is getting a
list of all packages. The groups it offers are not exhaustive (as they come
from comps, then are modified at PackageKit level, but in any case they
don't cover everything in the repo). But I don't think gnome-packagekit
allows that either and I don't think there are any alternatives being
considered at this time. (IMHO gnome-packagekit is not an option.)
> 2. networkmanager: the gnome icon in the system tray works splendidly
> here. Does absolutely everything have to be duplicated? But, if it does,
> then I would think it should be, at a minimum, as functional as the
> current system. I like it in the system tray, as having a plasmoid for
> this uses up too much space on the panel.
The current KNM is a systray icon and it is fully functional AFAICT. It just
works for me. I don't see why we'd continue shipping NM-gnome. That was just
a temporary workaround when KNM wasn't working properly yet.
I think we should keep in mind that we are a *KDE* spin, we shouldn't
pollute the spin with GNOME apps unless there's really no KDE option. If the
KDE app is not good enough, we need to get the KDE app improved, not ship
the GNOME one. I'd see switching back from a KDE app to a GNOME one as a
regression.
A big issue is that if we work on integrating the GNOME apps into the KDE
spin, we end up doing things like removing OnlyShowIn/NotShowIn which in
turn makes life a PITA for those folks who really want the KDE option. E.g.
if we enable gnome-packagekit in KDE (which it currently is not), then
people can't use KPackageKit properly anymore unless they either remove
gnome-packagekit (which can break dependencies depending on what they have
installed, and is also not an option on a multi-user system with GNOME
users) or manually edit its .desktop file (which gets clobbered on gnome-
packagekit updates and which also breaks DeltaRPMs for gnome-packagekit, so
it's not something we should encourage). We already had that problem when we
wanted to offer KPackageKit for F9, we couldn't make it the default due to
this issue. (IIRC, rpm -e gnome-packagekit is what I did on my F9 systems to
solve the problem. But as I explained, it's not an option for everyone.) So
we'd be doing a big disservice to the people (like me) who want to run a
pure KDE. (I'm fine with using GNOME/GTK+ apps where they are the only (or
the only Free as in speech, e.g. I'll take Ekiga over Skype any day!)
option, but not where there is a functional KDE app which integrates much
better available. Especially system-related services like package management
and Bluetooth really need an application which works together with the rest
of the desktop. For example, gnome-bluetooth tries to use things like
gio/gvfs, which is not appropriate in KDE.)
Kevin Kofler
