OK guys, here's the item that I've been working on with the JPackage
folks for a while:
http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage
This exception documents how Java packages which come from JPackage are
to be handled, and paves the way for the eventual removal of the jpp
tag.
Fernando Nasser, Jesse Keating, and many others helped me put this
together, and they all seem pretty happy with what we've got in this
final draft.
FPC members: Please vote on this item.
Thanks,
~spot

Hiyas,
I want to ask for a Guideline on how to name plugins for a program/package.
Here are some examples of current plugin names:
xfce4-wavelan-plugin
thunar-media-tags-plugin
nagios-plugins-real
p7zip-plugins
lineak-xosdplugin
digikamimageplugins
childsplay_plugins
audacious-docklet
I want to propose to use
<package>-plugin-<pluginname>
for rpms that contain one special plugin and
<package>-plugins or <package>-plugins-<pluginscollectionname>
for rpms that contain several plugins.
This would make it a lot easier for a user to install or look for all plugins
of a given package, e.g. with
yum list audacious-plugin\*
yum install audacious-plugin\*
Regards,
Till

Hiyas,
I want to propose to add a link to a page to the PackagingGuidelines on
compiler flags that explain why which compiler flags should be set and why
some should not set. I made a page with some examples:
http://fedoraproject.org/wiki/TillMaas/CompilerFlags
Regards,
Till

Currently extensions such as php-Smarty install their php Class files
in /usr/share
This should change to /usr/share/php, and the default php include_path
should include /usr/share/php
This will allow endusers to simply have in their php files:
include 'foo/foo.php'
instead of:
include '/usr/share/foo/foo.php'
And basically things will "just work" as expected. Seems other
distros do this as well.
I have filed bugs against php and php-Smarty:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225434https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225436
Can we add this to the packaging guidelines for php classes other than pear?
Regards,
Chris

Hey,
Yesterday I stumbled over an interesting dependency mishap wrt to
Inkscape: it is pulling in wxGTK, even though it is not using that
toolkit. This was caused by an unintended (automatic) provides in
some perl package
( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224238 ).
This made me think that it would be a good idea to add an item to
the package review to check the list of provides for sanity, much
like we have an item to check for unintended directory ownerships.
Also, it would be great to do a "duplicate provides" review of
the whole repository, but I'm currently at a loss of knowledge
about good tools for such a thing. What is the best tool to enumerate
the full package/provides matrix for a repository ?
Matthias

Hi,
I will try to summarize the findings so far.
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.
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.
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
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.
P.S.: If we could get the fixes for 3a and 3b we could get rid of the
'jpp' immediately. Anyone that could help me with those?
Fernando