On Mon, 2008-09-22 at 11:22 -0700, Jesse Keating wrote:
> So your solution is to invent something else entirely, rather than
> helping Fedora clean up its groupings definitions? Really? Nice.

No. PK groups are made up _from_ the comps groups. There are just an
order of magnitude less options, and it's a flat list rather than a
tree. Comps supports optional, mandatory, suggested and the sort of
power user stuff that I just don't want to support in PackageKit.

For me to "clean up the groups" would be to rip out all optional groups,
rip out most of the obscure categories and add lots of packages with
lots of extra deps. I'm sure that's not what you want me to do with
comps at all.

If you want to actually help with this stuff, can I suggest you join the
PackageKit mailing list and discuss there? Fedora isn't the only
consumer of PackageKit, and I'm keen on working upstream on ideas and
policies with other distros rather than just defending decisions made
upstream that affect fedora.

And just correcting you: this wasn't _my_ decision, this was the result
of working with lots of other distros. Sarcasm doesn't help anybody.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, Sep 22, 2008 at 3:43 PM, Richard Hughes <hughsient@gmail.com> wrote:
> On Mon, 2008-09-22 at 11:22 -0700, Jesse Keating wrote:
>> So your solution is to invent something else entirely, rather than
>> helping Fedora clean up its groupings definitions? Really? Nice.
>
> No. PK groups are made up _from_ the comps groups. There are just an
> order of magnitude less options, and it's a flat list rather than a
> tree. Comps supports optional, mandatory, suggested and the sort of
> power user stuff that I just don't want to support in PackageKit.


You should have said this earlier. This puts this discussion in the
hands of UI and design specialists, as opposed to developers. Which
may mean that Fedora is the wrong place to do most of this work.
Because this suggests that this tool will be useless to me. I tried to
use packagekit when I first installed it. I was taking some notes to
file bugs, but these will likely not be of interest as they are aimed
more at users like myself.

There is no reason why an abstracted GUI should be less easy to use than yum.


--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating <jkeating <at> redhat.com> writes:
> I won't argue that it could use improvement. I will however argue that
> the way to improve it is to have dialog with those using it and
> producing it, rather than deciding off project somewhere to just ignore
> it or apply filtering/modification to it without consulting the project
> at all.

Indeed. PackageKit should be fixed to use comps groups unmunged. Unfortunately,
PackageKit's design is fundamentally broken and thus fixing this needs API
changes. See this enum:
typedef enum {
PK_GROUP_ENUM_ACCESSIBILITY,
PK_GROUP_ENUM_ACCESSORIES,
PK_GROUP_ENUM_ADMIN_TOOLS,
PK_GROUP_ENUM_COMMUNICATION,
PK_GROUP_ENUM_DESKTOP_GNOME,
PK_GROUP_ENUM_DESKTOP_KDE,
PK_GROUP_ENUM_DESKTOP_OTHER,
PK_GROUP_ENUM_DESKTOP_XFCE,
PK_GROUP_ENUM_EDUCATION,
PK_GROUP_ENUM_FONTS,
PK_GROUP_ENUM_GAMES,
PK_GROUP_ENUM_GRAPHICS,
PK_GROUP_ENUM_INTERNET,
PK_GROUP_ENUM_LEGACY,
PK_GROUP_ENUM_LOCALIZATION,
PK_GROUP_ENUM_MAPS,
PK_GROUP_ENUM_MULTIMEDIA,
PK_GROUP_ENUM_NETWORK,
PK_GROUP_ENUM_OFFICE,
PK_GROUP_ENUM_OTHER,
PK_GROUP_ENUM_POWER_MANAGEMENT,
PK_GROUP_ENUM_PROGRAMMING,
PK_GROUP_ENUM_PUBLISHING,
PK_GROUP_ENUM_REPOS,
PK_GROUP_ENUM_SECURITY,
PK_GROUP_ENUM_SERVERS,
PK_GROUP_ENUM_SYSTEM,
PK_GROUP_ENUM_VIRTUALIZATION,
PK_GROUP_ENUM_SCIENCE,
PK_GROUP_ENUM_DOCUMENTATION,
PK_GROUP_ENUM_ELECTRONICS,
PK_GROUP_ENUM_COLLECTIONS,
PK_GROUP_ENUM_UNKNOWN
} PkGroupEnum;
This enum is all the way down in libpackagekit and the backends have no control
over its contents. This is exactly how things should NOT be done! The list of
groups should be determined by the backend (entirely, not as a bitfield of
the "which of the groups in the enum do we support" type). It should be the
backend's task to return a string and an optional icon (with a sane default,
like that "metapackage" icon) for each of the groups which are actually
present, they should not have to force their groups into a set of hardcoded
integers (and throw away everything the enum doesn't cover). The current system
is overly simplistic, inflexible and just plain dumb.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/9/23 Nicolas Mailhot <nicolas.mailhot@laposte.net>:
> Le lundi 22 septembre 2008 à 09:15 -0400, Matthias Clasen a écrit :
>> On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote:
>> > Le lundi 22 septembre 2008 à 07:01 +0200, Thorsten Leemhuis a écrit :
>> > > On 21.09.2008 23:33, Kevin Kofler wrote:
>> > > > Tim Lauridsen <tim.lauridsen <at> googlemail.com> writes:
>> > > > [...]
>> > > > IMHO, a much better approach would be to:
>> > > > * throw out the hardcoded categories! We have that information in compsxml,
>> > > > PackageKit should not try to duplicate it.
>> >
>> > The PK argument used to be comps groups suck, are distro-specific, have
>> > no equivalent on some distros, so people should drop comps and
>> > contribute to pk hardcoded stuff instead.
>>
>> Where did you get that idea ?
>
> Already had many exchanges with Richard on the subject


If this is the idea, then this needs to be done at the LSB level, and
let it filter down to the distros. Frankly, I thought the idea was to
fit into each distro, not override each distro


--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-09-23 at 09:00 +0200, Nicolas Mailhot wrote:
> But we're not interested in improving PK. We're interested in
> improving Fedora. If PK intends to focus on a non-Fedora user, we're
> not interested in PK are we?

I don't respond to silly threats, sorry.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, Sep 22, 2008 at 11:45 PM, Richard Hughes <hughsient@gmail.com> 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/9/23 James Antill <james.antill@redhat.com>:
>
> _Well done_ for bringing up rpm specfile groups which are obsolete, as
> I'm sure you know, and have been since before PK existed.

I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?

Also, right now, rpmdev-newspec still creates a Group field, and even
prepopulates it for certain templates (e.g. libraries)

Regards,

--
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim@cs.indiana.edu
Fedora • salimma@fedoraproject.org
MacPorts • hircus@macports.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Michel Salim wrote:

2008/9/23 James Antill <james.antill@redhat.com>:

_Well done_ for bringing up rpm specfile groups which are obsolete, as
I'm sure you know, and have been since before PK existed.


I've been wondering -- is there any reason we don't get rpmbuild to
strip the group out of the package metadata when it generates a binary
RPM?


Smart, Apt and probably others still rely on those IIRC. If they are
taught to use comps, we can get rid of the rpm groups.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-09-25 at 20:47 -0400, Michel Salim wrote:
> 2008/9/23 James Antill <james.antill@redhat.com>:
> >
> > _Well done_ for bringing up rpm specfile groups which are obsolete, as
> > I'm sure you know, and have been since before PK existed.
>
> I've been wondering -- is there any reason we don't get rpmbuild to
> strip the group out of the package metadata when it generates a binary
> RPM?
>
> Also, right now, rpmdev-newspec still creates a Group field, and even
> prepopulates it for certain templates (e.g. libraries)


it'll be maintained for compat reasons by it is no longer required to
build a package as of the new rpm in rawhide, iirc.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list