[Fedora-packaging] Java naming scheme

Fernando Nasser fnasser at redhat.com
Thu Jan 18 20:51:39 UTC 2007

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?



More information about the Fedora-packaging mailing list