Exception for JPackage
by Tom Callaway
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
16 years, 4 months
plugin naming
by Till Maas
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
16 years, 4 months
Unused direct shared library dependencies and rpmlint
by Ville Skyttä
Hi,
Inspired by
http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html,
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.
Example output:
$ 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
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.
16 years, 4 months
erroneous provides
by Matthias Clasen
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,
perl(Class::Struct::Tie_ISA).
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.
Matthias
Finally, the list:
postgresql-contrib: autoinc.so
postgresql-test: autoinc.so
mod_perl: Base64.so
perl: Base64.so
samba: cap.so
zsh: cap.so
aqbanking: csv.so.0
gwenhywfar: csv.so.0
python: datetime.so
zsh: datetime.so
xen: fsimage.so
xen-libs: fsimage.so
mailman: hangul.so
scim-hangul: hangul.so
rhpl: iconv.so
ruby-libs: iconv.so
scim-bridge-gtk: im-scim-bridge.so
scim-bridge-qt: im-scim-bridge.so
gnu-crypto-sasl-jdk1.4: java-sasl
java-1.4.2-gcj-compat: java-sasl
java-1.4.2-gcj-compat: jaxp_parser_impl
xerces-j2: jaxp_parser_impl
mkinitrd: libbdevid.so.6.0.6
nash: libbdevid.so.6.0.6
lam-libs: libmpi.so.0
openmpi-libs: libmpi.so.0
compiz: libsvg.so
librsvg2: libsvg.so
perl-DBD-MySQL: mysql.so
php-mysql: mysql.so
ccid: pcsc-ifd-handler
ifd-egate: pcsc-ifd-handler
automake15: perl(Class::Struct::Tie_ISA)
perl: perl(Class::Struct::Tie_ISA)
perl-Carp-Clan: perl(DB)
perl: perl(DB)
gaim: perl.so
xchat: perl.so
python: pyexpat.so
PyXML: pyexpat.so
python: readline.so
ruby-libs: readline.so
postgresql-contrib: refint.so
postgresql-test: refint.so
perl-PDL: RNG.so
python-numeric: RNG.so
postfix: smtpdaemon
sendmail: smtpdaemon
mod_perl: Socket.so
perl: Socket.so
perl-Crypt-SSLeay: SSLeay.so
perl-Net-SSLeay: SSLeay.so
perl-PDL: Storable.so
perl: Storable.so
python: syslog.so
ruby-libs: syslog.so
postfix: /usr/bin/mailq
sendmail: /usr/bin/mailq
postfix: /usr/bin/newaliases
sendmail: /usr/bin/newaliases
postfix: /usr/bin/rmail
sendmail: /usr/bin/rmail
postfix: /usr/sbin/sendmail
sendmail: /usr/sbin/sendmail
mod_perl: Util.so
perl: Util.so
ImageMagick: xc.so
xen: xc.so
php-mysql: php_database
php-odbc: php_database
php-pgsql: php_database
selinux-policy-mls: selinux-policy-base
selinux-policy-strict: selinux-policy-base
selinux-policy-targeted: selinux-policy-base
gnome-python2-bonobo: ui.so
gnome-python2-gnomeprint: ui.so
gnome-python2: ui.so
ruby-libs: socket.so
scim-libs: socket.so
scim: socket.so
zsh: socket.so
elinks: webclient
firefox: webclient
lynx: webclient
w3m: webclient
wget: webclient
16 years, 4 months
erroneous provides
by Matthias Clasen
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
16 years, 4 months
Java naming scheme
by Fernando Nasser
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
16 years, 4 months
