Hi all!

I recently created comps.xml files for RPM Fusion. During that a few
things around comps.xml got discussed on the RPM Fusion lists(¹).

That and a recent change (²) to
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
made me wonder:


How important is comps.xml to us these days?


(Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion
for things like this just follows the Fedora guidelines)


Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).


Thus for most packages it doesn't matter much if they are missing in
comps.xml -- if they are missing there they will not be able to select
in anaconda during install, but that's all. Which brings me to the
second question:



Which packages should be in comps.xml and which not?


Round about two years ago (e.g. before the merge) we IIRC for a short
while mainly said and acted like this: round about everything that is
not a lib (those normally get tracked in by deps when needed) or a devel
package should be mentioned in comps.xml; that of course included
command line apps(³). Note sure if it ever made it to the guidelines
with these or similar words; likely not. These days the wiki says:



If you maintain an application which makes sense for a user to select
during installation, [...] make sure that your package is listed in a
reasonable group in the comps-fn.xml.in files.


I consider the "during installation" part not much helpful because a
package that seems unimportant during installation for 99% of the users
might be something a few other users will look out for. Heck, some new
Fedora users might even abort the Fedora install at this point if they
miss a package they really plan to use with Fedora.


But that is only one of the problems afaics; according to

http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing

there are 2866 packages in comps-f10 and 1711 packages missing (seems
the SRPMS are used as a base here; I'm wondering if using RPMs might be
more wise, but that is just one more thing to discuss); some of

those 1711 really are in fedora for quite a while and really look to me
like worthwhile mentioning in comps.xml (see above), to make sure people
can find and select them right during install with anaconda. Do we care?


Cu
knurd

(¹) doesn't matter much for this discussion, but for the curious see
this thread
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001027.html

(²)
https://fedoraproject.org/w/index.php?title=PackageMaintainers%2FCompsXml&diff =49865&oldid=36786

(³) see also
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001103.html

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

Thorsten Leemhuis wrote:



Comps.xml is afaics mainly used in anaconda (and thus indirectly in
tools like pungi that rely on anaconda) and yum (if you know what to do)
these days; PackageKit afaics doesn't use it much (or does it use
comps.xml at all? Will that change?); it just lists everything it finds
afaics (correct me if I'm wrong, I'm not using PackageKit much and just
use yum directly).


PackageKit does use it via the yum backend.

http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/

Rahul

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

On Mon, 2008-09-22 at 09:49 +0100, Richard Hughes wrote:
>
> It's not. Groups are a subset of the comps groups. I've done substantial
> user research, and I'm sorry to say fine grained categories _do not
> work_ with real users. None of the people in
> http://www.packagekit.org/pk-profiles.html could tell me what they
> expected to find in base-system/system-tools or base-system/admin-tools,
> or tell me the difference between them.

So your solution is to invent something else entirely, rather than
helping Fedora clean up its groupings definitions? Really? Nice.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote:
> 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.

Well that's just too damn bad. You're making things /worse/ by having a
different view of things post-install than you had during install. This
was one of the /best/ things about pirut is that you got the same
familiar UI, whether that UI was good or bad didn't matter, it was
the /same/ and /consistent/.

>
> 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.

Well it'd certainly be a starting point for a conversation, which is
much better than decisions being made about our distribution and what
our users see in our distribution discussed and made somewhere that
was /not/ our distribution. Hurting, not helping.

> 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.

If I'd known that upstream was actively looking to destroy our package
classifications, rather than actually work with us to clean them up a
bit maybe I would have joined the conversation. A heads up might have
been in order. I fear that any conversation now will just be too little
too late.

> 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.

Neither does letting other distributions make decisions about ours.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-09-22 at 15:21 -0700, Jesse Keating wrote:
> On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote:
> > 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.
>
> Well that's just too damn bad. You're making things /worse/ by having a
> different view of things post-install than you had during install. This
> was one of the /best/ things about pirut is that you got the same
> familiar UI, whether that UI was good or bad didn't matter, it was
> the /same/ and /consistent/.
>
> >
> > 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.
>
> Well it'd certainly be a starting point for a conversation, which is
> much better than decisions being made about our distribution and what
> our users see in our distribution discussed and made somewhere that
> was /not/ our distribution. Hurting, not helping.
>
> > 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.
>
> If I'd known that upstream was actively looking to destroy our package
> classifications, rather than actually work with us to clean them up a
> bit maybe I would have joined the conversation. A heads up might have
> been in order. I fear that any conversation now will just be too little
> too late.
>
> > 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.
>
> Neither does letting other distributions make decisions about ours.


Thanks Jesse, for making it clear that you are more interested in
confrontation than a constructive discussion impossible.

People who are interested in improving PackageKit should probably take
the discussion to the packagekit list (packagekit@lists.freedesktop.org)



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

On Mon, 2008-09-22 at 18:52 -0400, Matthias Clasen wrote:
> Thanks Jesse, for making it clear that you are more interested in
> confrontation than a constructive discussion impossible.

I'm interested in fixing our comps files, since that's what is used by
our installer, our compose tools, our package tools such as yum, our
developers, our documentation, etc, etc...

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.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Le lundi 22 septembre 2008 à 18:52 -0400, Matthias Clasen a écrit :
> On Mon, 2008-09-22 at 15:21 -0700, Jesse Keating wrote:
> > On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote:

> > > 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.
> >
> > Neither does letting other distributions make decisions about ours.
>
>
> Thanks Jesse, for making it clear that you are more interested in
> confrontation than a constructive discussion impossible.

Constructive discussion needs to be 2 way. I had to write down the PK
position on this for people on fedora-devel to learn what decisions were
being made for them. And the decisions touched packaging which is
fedora-devel main subject. (unfortunately the desktop team mislike for
the common distro communication channel is not new).

I sure hope the "other distro representatives" we've read so much on
were more representative than the Fedora ones.

> People who are interested in improving PackageKit should probably take
> the discussion to the packagekit list (packagekit@lists.freedesktop.org)

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?

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

Le Mar 23 septembre 2008 09:00, Nicolas Mailhot a écrit :
> Le lundi 22 septembre 2008 à 18:52 -0400, Matthias Clasen a écrit :

>> Thanks Jesse, for making it clear that you are more interested in
>> confrontation than a constructive discussion impossible.
>
> Constructive discussion needs to be 2 way.

Sorry, got carried over. I apologise for the abrasiveness.

Still, any decision concerning the way we install or update the distro
is releng territory IMHO, and I'm distressed that Jesse didn't seem to
be in the loop at all.

(I could live with PK people disagreeing with me. That's ok, I
disagree with lots of people)

--
Nicolas Mailhot


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

On Fri, 2008-09-26 at 06:20 +0530, Rahul Sundaram wrote:
> 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.

No, we won't be waiting for those to catch up.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 26 Sep 2008, seth vidal wrote:


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.


Yup. We can't drop off the group tag just like that, not only various
software expects it to be there, it's documented as a mandatory field in
LSB.


rpmbuild no longer requires the Group: tag in specs, but it drops in
"Unspecified" if the spec doesn't set it to comply (the current rawhide
rpm wont do this but it's fixed upstream, rawhide will get it in next

version update)

- Panu -

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