Toshio Kuratomi wrote:
(...)
You missed the "P.S."
I am creating a patch for Groups because Categories are not there yet,
so I can't do anything for it ATM. Once Groups are abandoned in favor
of Categories, the functionality available for Groups must be adapted to
work with Categories instead.
I read that but perhaps one of us is misinterpreting the other. I'm
saying the following:
1) Keeping group and category functionality in rpm's spec file is going
to be deprecated for Fedora.
Oh, I thought the Group functionality was being deprecated but we would
have a Category one to replace it (where packages could belong to many
instead of a single one).
So I did misunderstood that. I even thought you wanted to store the
Categories in the RPM database. If that was the case it was just a
different Query (on Categories instead of Groups, and I would not even
need a glob pattern in that case).
2) rpm doesn't have any business reading an external xml file from the
repository.
Therefore any Group functionality added to rpm now, should be
implemented outside of rpm when we get Categories. As long as you're
okay with the functionality that you're currently implementing being
moved to another tool (for instance, yum or a program in yum-utils) then
I'm okay with this.
That is what I haven't understood. It doesn't have to be in rpm at all,
anything that produces the list of packages in that Category can be used.
In any case, I am not trying to add any new switch or functionality,
just fix an existing one that has an annoying shortcoming ('rpm -q
--group' does not take a regexp/glob).
That's fine. Like I say I'm not judging how likely it'll get into rpm,
just that the functionality probably needs to live in another tool when
we move to categories.
It is OK. I was just trying to accelerate things but perhaps it would
be wise to wait a little bit,
Are we removing the Groups table from the database?
(...)
One controversy with using the yum group functionality for this is that
it uses comps.xml to achieve its ends. Jeremy Katz is against using
comps.xml to make categories that shouldn't be visible to the installer.
skvidal has shown how we could have multiple comps.xml files that yum
reads (whereas the installer only reads from one) which addresses a few
of Jeremy's concerns. When we go ahead with this we'll have to work out
whether we're going to store the information in a comps file or teach
yum about a new grouping file format.
In any case, there will be always something for groupinstall,
groupupdate, groupremove, groupinfo and also a --groupexclude to do the
selection.
Yep. Just letting you know if you're doing some hacking in this area to
be aware that the backend could change here. And it's early in the
process so you can be a part of making this decision as well.
Is that wiki page you've pointed us to the only place to watch ATM?
http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements
Regards,
Fernando
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
