[Fedora-packaging] Java naming scheme

Fernando Nasser fnasser at redhat.com
Thu Jan 18 14:26:40 UTC 2007


Hi Toshio,

Toshio Kuratomi wrote:
> On Wed, 2007-01-17 at 16:23 -0500, Fernando Nasser wrote:
>> 1) We seem to agree that we want to make the following transformation on 
>> the release fields :
>>
>> 3jpp -> 3.1 in Fedora
>>
>> This will satisfy all our upgrade paths, as:
>>
>> 4.1 > 4jpp > 3.1 > 3jpp
>>
>> so one can always have the latest fixes.
>>
> Spot brought the 3jpp.fc6.1 format to the packaging group which was
> discussed and agreed as a possible temporary format.  Unfortunately,
> 3jpp.fc6.1 doesn't work for interleaving with jpackage if jpp is
> removed.  So we'll probably have to have another (hopefully short)
> discussion about using 3jpp.1.fc6 & 3.1.fc6.
> 

Why the %{_dist} is necessary here?  Can't we just add the number?
I thought we would need the %{_dist} only if we needed to have the same 
RPM built in two different distro releases and they were release 
specific (depend on some shared library or something).


>> 2) Some would be agreeable to leaving the 'jpp' in there as a temporary 
>> measure, as what we really want is some Groups (or Categories) 
>> functionality that is not yet available.
>>
>> So, temporarely, 3jpp -> 3jpp.1
>>
> Yep.
> 
>> 3)  What do we need to get rid of the 'jpp'
>>
>> a) Query for the set of Java packages
>>
>> The rpm -qg (or rpm -q --group) command currently does not accept patterns
>>
>> If we could do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" 
>> tags of all Java packages and that would work.
>>
>> I am trying to create a patch for that (which would be RPM patch #37 in 
>> Fedora) but I am encountering some difficulties as it is the first time 
>> I am looking at the rpm source code and I have been working with Java 
>> rather than C in the last years.
>>
>> P.S.: We would need a similar query functionality when Categories 
>> replace Groups.
>>
> Although I can't speak for the likelihood of this getting into rpm, it's
> usefulness is going to be near nil.  The distribution is moving away
> from storing group information in the rpm spec file.  These reasons have
> been articulated by Jeremy Katz and others on fedora-devel many times in
> the past.
> 
> There are some pointers to the last discussion here:
> http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements
> 
> The page has the justification for moving away from the group tag at the
> top of the page although I think the discussion for that happened in
> previous discussions (so the threads that are linked will assume that
> everyone already knows the shortcomings of the Group tag.) 
> 
> Given this, I'd be very hesitant to make group functionality in rpm be
> one of the criteria to get rid of the jpp naming.
> 

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.

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


>> b) yum has already some group functionality (groupinstall, groupupdate, 
>> groupremove, groupinfo) that is based on an XML file that is kept in the 
>> repository.  But the option --exclude only acts on file names, we need a 
>> --groupexclude.
>>
>> We already have a "Java" group, with only 2 packages on it:
>>
>> # yum groupinfo Java
>> Loading "installonlyn" plugin
>> Setting up Group Process
>> Setting up repositories
>>
>> Group: Java
>>  Description: Support for running programs written in the Java 
>> programming language.
>>  Mandatory Packages:
>>    libgcj
>>    java-1.4.2-gcj-compat
>>
> If I understood spot's summary of your requirements, you want to
> categorize all the packages you are importing from jpackage.  I would
> point out that the java group would be a poor place to implement that as
> any java packages which did not come through jpackage could also
> legitimately be placed in there.
> 

We actually want all Java packages.  They are always extremely 
interrelated, with cascading effects among them, so they need to be 
treated as a whole.  Any Java package should be in there.

When categories become available, we can even be fancies and have the 
Java ones that are from Jpackage also in a specific category (I don't 
have a use case for that at the moment, but if necessary we could do it).


>> We could just make sure all Java packages are in the Java group to make 
>> use of the yum group functionality.
>> We just need the --groupexclude.
>>
>> I will try and create a patch to add a '--groupexclude' as soon as I 
>> finish with the rpm one.
>>
> 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.


Regards,
Fernando




More information about the Fedora-packaging mailing list