[Fedora-packaging] Java naming scheme

Toshio Kuratomi a.badger at gmail.com
Thu Jan 18 18:27:17 UTC 2007

On Thu, 2007-01-18 at 09:26 -0500, Fernando Nasser wrote:
> Hi Toshio,
> Toshio Kuratomi wrote:
> > 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).
Jesse seems to be answering this one.

> > 
> >> 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.
> >>
> > 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.
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.
2) rpm doesn't have any business reading an external xml file from the

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.

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

> >> 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.
Okay.  My misunderstanding then.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070118/64846a6b/attachment.sig>

More information about the Fedora-packaging mailing list