packaging June 2007

packaging@lists.fedoraproject.org

33 participants
36 discussions

Modifying upstream tarballs
by Jason L Tibbitts III 06 Jun '07

06 Jun '07

I understand that there are circumstances where the upstream tarballs need to be modified to removed content which is patented or cannot be redistributed for some reason. However, should that be the extent of the permitted modifications? Take, for example, this comment from a current review ticket: #Original from http://membres.lycos.fr/agisite/prof.zip includes #copyrighted executables. Generated new source by unzipping, removing #DOS-related content, running dos2unix on the text file, and changing #all filenames to lowercase for agistudio compatibility. Now, everything except the removal of the executables could be done at %prep time in the spec, and that's how we'd insist that things be done in the normal case where the upstream tarball (or zipfile, in this case) needs no modification. - J<

11 26

Call rpm during rpmbuild
by Richard W.M. Jones 05 Jun '07

05 Jun '07

I'm right in thinking that it's bad to call rpm from rpmbuild? During my find-requires script, I need to get the exact name-version-release of the ocaml compiler. Obviously the compiler knows its name & version, but not its release. At the moment I'm doing: if [ -n "$emit_compiler_version" ]; then # Every OCaml program depends on the precise version of the # compiler which was used to compile it. rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml fi but if calling rpm like this is bad, I'm wondering how to fix it. Best way I can see to do this is to store the name-version-release of the compiler in a special file in the ocaml RPM, something like: /usr/lib64/ocaml/fedora-ocaml-release which would contain something like 3.09.0-3 or whatever, then the script can be changed to cat this file. What do people think? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

4 5

Missing Packaging Meeting
by Toshio Kuratomi 05 Jun '07

05 Jun '07

I'll be in a training meeting and won't be able to make the meeting this Tuesday. -Toshio

2 1

Script to check gnomefiles.org for upstream updates
by Sindre Pedersen Bjordal 04 Jun '07

04 Jun '07

Hope this is the right list. Lots of upstream projects use gnomefiles.org, several of the packages I maintain use it to post news about updates. Gnomefiles.org offers a nice automatically generated XML document for accessing the version information. Inspired by the cpancheck.sh script for perl packages I wrote, with a lot of help from friendly people on irc, a script to check if packages maintained by a given user have version information on GnomeFiles and more importantly, if the version in fedora devel and GnomeFiles.org match. This way you can run this script and see if there's a new release of one of your packages. Like with the cpancheck.sh script you'll have to define your email, path to owners.list and path to your local Fedora cvsroot in the script itself. Script available here: http://folk.ntnu.no/sindrb/fedora/gnomefilescheck.sh Feedback very welcome, hope this is useful for someone besides me. -- Sindre Pedersen Bjørdal <foolish(a)guezz.net> - http://www.fedoraproject.org/wiki/SindrePedersenBjordal

1 0

paragraph on shipping static numerical libs updated
by Patrice Dumas 03 Jun '07

03 Jun '07

Hello, Here is an updated version of the paragraph about shipping static numerical libs taking into account the comments on the first version. The objective is to have this included in http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges at the end of 'Packaging Static Libraries'. * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages and this doesn't means that the executables packaged in Fedora should be link statically, this is only for users linking locally their own programs. Some packagers feel that this is not the right solution for locally compiled programs portability, since it is not general (doesn't work with nss, iconv...). However a general solution doesn't seems to exist yet. -- Pat

4 12

tricks for multilib proposal
by Patrice Dumas 02 Jun '07

02 Jun '07

Hello, I propose the following with tricks for packaging multilibs. It tries to be a summary of a thread about multilibs. There may be mistakes, or statements everybody doesn't agree with, so please comment. This is pseudo wiki and I don't know where it should be put in the wiki. = Multi lib tricks = == Architecture independent files == For architecture independent the conflicts should be avoided, so the files should be identical among arches. It may involve some work with upstream when header files include architecture specific files, for example header files which contains autoconf conditionals like HAVE_INT32. Files should also have the same timestamps. For most of the files this means taking care to keep the timestamps (which should be done in every package). For autoconf based packages this is in general achieved by doing something along: make install DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p" For the architecture independent files generated at build time it is possible to use the timestamp of a reference file. For example: touch -r ../cernlib.in src/scripts/cernlib or touch -r NEWS $RPM_BUILD_ROOT%{_includedir}/Xbae/patchlevel.h == Multiarch, binaries and compilation scripts == In multilib environments there is a preferred architecture, 64 bit over 32 bit in x86_64, 32 bit over 64 bit in ppc64. When a conflict is found between two packages corresponding with different arches, the installed file is the one from the preferred arch. This is very common for executables in /usr/bin, for example. If the file /usr/bin/foo is found in an x86_64 package and in an i386 package, the executable from x86_64 will be installed. These implicit conflicts are accepted in Fedora, though they are considered bad by some contributors. There may be some long-term solution for these issues, but before that there are some tricks that may allow to avoid those conflicts that are presented below. Once again they are optional. * In compilation scripts (in general named along mylib-config) it should be advisable to remove -L$libdir when $libdir is the default library directory on this platform. Indeed this is automatically added when linking with the gcc compiler (it may be needed when linking with ld, but using ld is wrong in general, so a user linking with ld should add the flag by himself). * binaries may be put outside of the packages selected to be included in multilib repositories. In general the devel subpackages and their dependencies are included in multilib repositories. A typical split of a package is: foo for the binaries foo-libs for the libraries foo-devel for the development headers, and development symlinks foo-devel and foo both requires foo-libs, and foo isn't present in multilib repository. * wrapper scripts may be used to run a binaries based on which one is present. Here is a script example (adapted from firefox) ARCH=$(uname -m) case $ARCH in x86_64 | ia64 | s390 ) LIB_DIR=/usr/lib64 SECONDARY_LIB_DIR=/usr/lib ;; * ) LIB_DIR=/usr/lib SECONDARY_LIB_DIR=/usr/lib64 ;; esac if [ ! -x $LIB_DIR/package-0.0.1/foo ]; then if [ ! -x $SECONDARY_LIB_DIR/package-0.0.1/foo ]; then echo "Error: $LIB_DIR/package-0.0.1/foo not found" if [ -d $SECONDARY_LIB_DIR ]; then echo " $SECONDARY_LIB_DIR/package-0.0.1/foo not found" fi exit 1 fi LIB_DIR=$SECONDARY_LIB_DIR fi Another way to handle those conflicts could be to have a different directory for each architecture, even for executables, enabling Fedora to be multiarch and not only multilib. -- Pat

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2007