[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 packaging
mailing list