packaging January 2007

packaging@lists.fedoraproject.org

28 participants
25 discussions

Exception for JPackage
by Tom Callaway 09 Feb '07

09 Feb '07

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

10 34

plugin naming
by Till Maas 08 Feb '07

08 Feb '07

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

2 1

DesktopFiles proposal, final wording
by Rex Dieter 31 Jan '07

31 Jan '07

As spot requested, here's an update to the wording of: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles to make it clear that desktop-file-install usage is mandatory to help ensure .desktop file safety and spec-compliance. -- Rex

3 6

more verbose PackagingGuidelinee on compiler flags
by Till Maas 30 Jan '07

30 Jan '07

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

1 0

PHP Extensions (other than pear) default install dir
by Christopher Stone 30 Jan '07

30 Jan '07

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=225434 https://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

1 0

Unused direct shared library dependencies and rpmlint
by Ville Skyttä 27 Jan '07

27 Jan '07

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.

3 2

BuildRequires proposal
by Michał Bentkowski 27 Jan '07

27 Jan '07

Hi! I've made a draft regarding to BuildRequires section of Packaging Guidelines. I propose to mention about mock there. Any opinions are welcomed. Draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires -- Michał Bentkowski mr.ecik(a)gmail.com

1 0

erroneous provides
by Matthias Clasen 26 Jan '07

26 Jan '07

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

6 8

erroneous provides
by Matthias Clasen 25 Jan '07

25 Jan '07

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

1 0

Java naming scheme
by Fernando Nasser 22 Jan '07

22 Jan '07

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

7 26

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2007