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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
