packaging May 2007

packaging@lists.fedoraproject.org

32 participants
22 discussions

Tcl packaging guidelines proposal
by Michael Thomas 02 Jan '08

02 Jan '08

I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback). Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893) http://fedoraproject.org/wiki/PackagingDrafts/Tcl Please let me know if I need to do anything to help get these draft guidelines adopted. Thanks, --Wart

4 10

font package naming
by Jens-Ulrik Petersen 21 Sep '07

21 Sep '07

Hi, I would like to propose adding the following text to our "Package Naming Guidelines". http://fedoraproject.org/wiki/Packaging/NamingGuidelines ''' == Fonts Packages == Font packages should be named with the upstream name appended with `-fonts`. Examples: {{{ bitmap-fonts dejavu-lgc-fonts ghostscript-fonts urw-fonts xorg-x11-fonts }}} ''' Should the text discuss what to do when the upstream name contains the word "font" already? See https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00794.h… and https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00262.html for some recent discussion of <upstreamname>-fonts vs fonts-<language> and "-fonts" vs "-font" for singlet font packages. Comments or objections? Jens ps We might even consider renaming some of our "fonts-*" packages to follow this naming scheme for F8.

4 10

Packaging guidelines for Emacsen add-on packages
by Jonathan Underwood 15 Aug '07

15 Aug '07

Dear Packaging Committee, I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns And I have added it to the table here: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates. Comments gladly received! Best wishes, Jonathan

7 49

Hardlinking *.pyc and *.pyo
by Ville Skyttä 19 Jun '07

19 Jun '07

Hello, Related to recent space saving discussions, I came across PLD's rpm-build-macros package recently, and found that they hardlink identical *.pyc and *.pyo. In a lot of cases, they're the same, and there's some potential for saving some MB "for free", on my FC6 x86_64 box: $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 Would save 11116544 The PLD implementation looks like this: # Hardlink binary identical .pyc and .pyo files # (idea by glen <at> pld-linux <dot> org) %__spec_install_post_py_hardlink {\ %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ if cmp -s "$a" "$b"; then \ ln -f "$a" "$b"; \ fi; \ done \ }; __spec_install_post_py_hardlink } } The use of "cmp" would require diffutils installed. Or the above could be converted to use hardlink instead (which would have to be made sure to be around) or maybe sha1sum (in coreutils, pretty much always around in buildroots). I suppose something like the above could be easily added to redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile or run after it in %__os_install_post. Worth it? Other comments?

5 7

OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones 11 Jun '07

11 Jun '07

Toshio Kuratomi wrote: > On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote: >> Nigel Jones wrote: >> > Hi everyone, >> > >> > While putting in a couple of packages for Extras Review I've stumbled >> > into a couple of issues regarding how Ocaml links libraries and how the >> > Fedora Packaging Guidelines are set. >> > >> > My packages in question are: >> > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) >> > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) >> > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) >> > >> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set >> > of dynamic libraries, and another set for development etc), sadly when >> > other packages like freetennis build, they staticly link to libraries >> > such as camlimages/ocamlSDL. >> > >> > I found it semi-suspect when I built freetennis, and hence why I asked >> > on bugzilla when I posted the three packages for review, however I did >> > some more questioning today and after a quick IRC discussion in #ocaml >> > was told: >> > >> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries >> > right? >> > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. >> > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. >> > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for >> > dynamic loading as static loading. >> > >> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk >> > (as well as the main ocaml package) store .a, .cma and .cmxa files in >> > /usr/lib/ocaml (and subfolders). >> > >> > As I'm only new to Fedora packaging, could someone please advise on >> > where I should from here on the matter and what the position of FESCO is >> > on Ocaml static libraries, and where I should go from here. >> > >> > Thanks, >> > >> > Nigel Jones >> >> I'm just wondering if anyone has any thoughts on this issue. >> >> I've talked to some more people in #ocaml (Freenode), who suggested that >> I try a patch by the name of 'scaml' which is a year or two old (and >> although can be manually applied to the ocaml source, it does not work >> (problems with assembly which I've not comfortable meddling with). >> >> We'd actually need to downgrade to 3.07 which was removed from Fedora in >> Feb 05 to get the patch working to satisfy the need for dynamic loading >> which I'm sure would upset a few people. >> >> Upstream already have a bug opened stating that they need to fix the >> issue but they have never updated it, or assigned it to anyone. >> >> So my main question is "where to from here?" > > I think, if the ocaml compiler doesn't support dynamic libraries, static > linking would be acceptable. This doesn't mean that we shouldn't press > upstream to add dynamic linking (and convert all our packages when that > becomes available) just an acknowledgment that fixing the limitation has > to be done upstream (it could be done by someone within Fedora but the > fix needs to go upstream). > > This is similar to allowing C libraries in even if they only build > statically. > > If I'm not understanding precisely what the limitation is, feel free to > clarify. There are two issues here: (a) Having OCaml binaries link dynamically instead of statically to OCaml libraries. (b) Writing a dynamic library in OCaml, and having it used by programs written in other languages, particularly C. I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible. You might also find this entertaining: http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5… Another issue which Xavier doesn't mention is the ability to fix a security bug in a shared library, and not require all dependent applications be recompiled. Well, there aren't many (any?) widely used OCaml libraries, and there aren't a lot of binaries which would need to be recompiled either. But it could be a problem for OCaml world domination plans. As for (b), the ability to write libraries in a sane language and have them called through a C API: This almost works. Well, it works well on i386, but there are some problems on x86-64. I'm looking forward to having this. It needs some tools to make it work well - it would be nice to have the C header files and the complex Makefile fragments to get it to work generated automatically. 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

3 16

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

paragraph on shipping static numerical libs
by Patrice Dumas 31 May '07

31 May '07

Hello, Here is a paragraph explaining why some libs may be usefull in their static version: * 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. -- Pat

11 69

Meaning of -devel
by Richard W.M. Jones 25 May '07

25 May '07

Is there a policy which describes precisely what should go into a -devel subpackage? Here is an example case where I'm unsure: In OCaml there's a thing called the "toplevel". Think of it as being like the python command line (where you just type "python" on its own, then start typing in Python expressions). $ ocaml -I +calendar Objective Caml version 3.09.3 # #load "unix.cma";; # #load "str.cma";; # #load "calendar.cma";; # let d = Printer.DatePrinter.from_string "2007-01-01";; val d : Printer.DatePrinter.t = <abstr> # Printer.DatePrinter.to_string (Date.next d `Week);; - : string = "2007-01-08" So my question: If I'm packaging ocaml-calendar (a library) then should the parts which make the above possible go into the main package or ocaml-calendar-devel? Note that as far as I can see in Python -- and I'm not hugely familiar with that language so forgive me if I've made a mistake -- but it seems they go in the main package. Another thing is that if I move the parts into the -devel subpackage, then ocaml-calendar will literally be empty! 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 6

Exit status in rpm scriptlets
by Miroslav Lichvar 24 May '07

24 May '07

>From http://fedoraproject.org/wiki/Packaging/ScriptletSnippets: "Most commands in the snippets in this document have a "|| :" appended to them. This little piece of code causes each such command to exit with a successful exit status whether or not the command worked. This is important because the scriptlet as a whole will error the moment it tries to execute a command that has a non-zero exit status." That's not quite correct, at least with rpm we have in Fedora. Scriptlets (contrary to build scripts) are not actually executed through sh -e, therefore a failed command won't cause the whole scriptlet to fail. Only the last command executed matters. Generally we want to have scriptlets that always succeed, so added "|| :" doesn't break anything, but in case where we want to fail the installation of the package (as in UsersAndGroups packaging draft that wants to abort installation if required user isn't available) this doesn't work as one might expect. For scriptlets that should always return 0 just add : as the last line of the script and add "|| exit 1" to a command that should abort the whole script when failed. -- Miroslav Lichvar

1 0

Draft Changes to static libraries
by Toshio Kuratomi 22 May '07

22 May '07

I've written a draft of changes to the static library guidelines:: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges There are three pieces which can be voted on separately or together depending on how controversial they are: 1) Separate static library inclusion from static library linkage and make static library inclusion less strict. 2) Change how to package static libraries when the package does not include dynamic libraries (per Ralf's note to the list) 3) Incorporate mschwendt's note about *.la files directly into the guidelines instead of as a footnote. Comments welcome. == Exclusion of Static Libraries == Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. === Packaging Static Libraries === * In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. * We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance.) * When a package provides both dynamic and static libraries the static libraries must be placed in a ''*-static'' subpackage. Separating the static libs from the other development files in ''*-devel'' allow us to track this usage by checking which packages Build''''''Require the ''*-static'' package. * When a package only provides static libraries you can place all the files in the ''*-devel'' subpackage. When doing this you also have to have a virtual Provide for the static package: {{{ %package devel Provides: foo-static = %{version}-%{release} }}} This way other packages which will link against a dynamic library when your package starts providing one can {{{BuildRequire: foo-devel}}} and packages which explicitly need to link against the static version can {{{BuildRequire: foo-static}}} === Staticly Linking Executables === * Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval. -Toshio

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2007