[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How important is comps.xml to us these days? Which packages should be in comps.xml and which not?

Richard Hughes <hughsient <at> gmail.com> writes:
> You think we NEED a "KDE Software Development group". PackageKit is not
> designed for you. Can you explain how having fine grained groups would
> help people like: http://www.packagekit.org/pk-profiles.html ?

Well, at least the med student could have a use for a "medical applications" 
group (which I'm aware does not currently exist, but that's not PackageKit's 
problem ;-) ), if not now, at least in the future. And you have only 3 
profiles, that's a pretty small sample of all the users around, I'm sure there 
are many more users with needs for at least one specialized group (with the end 
result that _all_ specialized groups are needed).

> PackageKit is not designed for the sort of users who are comfortable
> using yum on the command line. PackageKit doesn't replace yum, it's just
> complimentary.

Power users can benefit a lot from a UI which is designed with them in mind. I 
don't consider this "design for newbies only, power users can just use the 
command line" premise helpful.

> If we designed PK as a "suitable for any user" tool then
> it would be suitable for no-one. Hence the need for a profiles page.

That's an assumption which has yet to be proven. For example, KDE aims at being 
usable both by new users and by power users and is IMHO fairly successful at 

And another issue is that the library design doesn't allow making a more 
powerful UI on top of the same library, because the "simple" groups are 
hardcoded and there's no API to get to the actual groups. Even if we accept 
your premise that a package manager for power users necessarily has to be a 
different application, it would still be nice to be able to build it on the 
same library. Reinventing the wheel to work around library limitations would be 
a big waste. For example, KPackageKit could potentially be that "more powerful 
UI" if the library allowed it.

        Kevin Kofler

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]