OK guys, here's the item that I've been working on with the JPackage
folks for a while:
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
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
FPC members: Please vote on this item.
I want to ask for a Guideline on how to name plugins for a program/package.
Here are some examples of current plugin names:
I want to propose to use
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\*
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:
Currently extensions such as php-Smarty install their php Class files
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:
And basically things will "just work" as expected. Seems other
distros do this as well.
I have filed bugs against php and php-Smarty:
Can we add this to the packaging guidelines for php classes other than pear?
I've had a patch for rpmlint in my local tree for a while which checks for
unused direct shared library dependencies in shared libs.
I'm wondering whether this check is a good idea; I'm not an expert in this
area and the check does produce quite a bit of output on some packages.
Comments very much welcome. At the moment I'm leaning towards including
this in the next rpmlint release anyway.
For the adventurous, grab the latest rpmlint from svn (see
http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/README.devel) and apply
the attached patch to BinariesCheck.py.
$ rpmlint krb5-libs | grep shlib
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkrb5support.so.0.1 /lib/libresolv.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libk5crypto.so.3.0 /lib/libresolv.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libdl.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libkdb5.so.4.0 /lib/libresolv.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libkrb5.so.3
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /usr/lib/libk5crypto.so.3
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssrpc.so.4.0 /lib/libcom_err.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libdl.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libgssapi_krb5.so.2.2 /lib/libresolv.so.2
W: krb5-libs unused-direct-shlib-dependency /usr/lib/libdes425.so.3.0 /lib/libcom_err.so.2
$ rpmlint -I unused-direct-shlib-dependency
The binary contains unused direct shared library dependencies. This may
indicate gratuitously bloated linkage; check that the binary has been linked
with the intended shared libraries only.
I have looked a bit at the provides in Core, and after a bit of creative
repoquery use, came up with the list of duplicate provides below.
A bunch of them is intentional, like smtpdaemon, webclient or
php_database. The bulk of it is due to non-library DSOs and is probably
relatively harmless. Some of them may be real errors, like libmpi.so.0,
So it looks like things are in relatively good shape in Core. I haven't
completed the same analysis for Core+Extras.
A couple of questions come out of this excercise:
1) Why does rpm keep all those non-library DSOs as provides ? Thats
blowing up the list of provides significantly, causing a lot of
duplicates, and is unlikely to ever be used for ever satisfying a
requires, unless it is in error (e.g. see libsvg.so in the list)
2) Is rpm smart enough to disambiguate provides based on the full path,
or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so
going to be used to satisfy a requires for a shared library with the
same name ? I guess this will rarely be a problem, since the shared
library requirement will be against something like libsvg.so.4.
Finally, the list:
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 ?
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
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
Description: Support for running programs written in the Java
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?