[Fedora-packaging] Java naming scheme
a.badger at gmail.com
Thu Jan 18 07:02:51 UTC 2007
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.
> 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
> 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
There are some pointers to the last discussion here:
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.
> 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
> 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:
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 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Fedora-packaging