On Mon, Sep 22, 2008 at 11:45 PM, Richard Hughes <hughsient@xxxxxxxxx> wrote: > 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 ? > > 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. 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. Can the motivating profiles for PK be extended to include situations where an instituttion is looking to create its own group definition for inhouse software for specific desktop users tasking? For example the medical school that your example medical student goes to may very well want to give its linux users a centralized way to access inhouse curriculum software utilities and may feel the best way to do that is to provide a dedicated grouping in a comps file definition in its local school package repository. Will PK grow to help those institutional users? Are you asking institutions who are running local, non-public, repositories to tell their medical student analogs to drop to the cmdline to install the inhouse software utilities via yum groupinstall, instead of exposing the institution's groupings via PK UI? The best part of comps to me, is the fact that local, non-public, institutional repositories have the flexibility to define their own groupings that best meet their situational needs.. without getting stuck in the god forsaken debate over how a particular distribution chooses to organize things. For academic institutions like medical schools, that could end up looking like curriculum or courseware groupings... grouping concepts we'd never ever need to consider in the most general case. Can anyone say that's not a valid way to make use of the flexiblity comps in an institutional setting? I can't. -jef"We can probably spend the next several months doing nothing more but nitpick how we group things in Fedora's comps. Or in fact nitpicking how anyone defines a group. I'm sure historians who focus on brick and mortar library catelog schemes will get a big kick out of it."spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
