packaging July 2011

packaging@lists.fedoraproject.org

18 participants
9 discussions

define versus global !?
by Farkas Levente 19 Aug '11

19 Aug '11

hi, sorry for cross posting but may be someone on the packaging/rpm side can help me. i'm getting really angry about the debug packages:-) does anybody who can tell me the real reason of why: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ works why ------------------------------------ %global __debug_install_post %{mingw_debug_install_post} ------------------------------------ not? imho if i can know the answer to this question i can solve my only remaining issue with generated spec file for mingw. if why this in the spec file working: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ while this not: test: ------------------------------------ echo "%define __debug_install_post %{mingw_debug_install_post}" ------------------------------------ and in the spec file: ------------------------------------ %global test sh /tmp/test %{expand:%(%{test})} ------------------------------------ ??? the same thing is working for all other macro except for __debug_install_post. thanks in advance. regards. -- Levente "Si vis pacem para bellum!"

5 7

Systemd scriptlet comments
by Ville Skyttä 09 Aug '11

09 Aug '11

Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd 1) I don't think the versioned trigger logic will work too well at all in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example: %triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here 2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets, only the final exit status of a script has any effect. 3) More or less cosmetic: why hardwire absolute paths everywhere? The vast majority of other scriptlet snippets don't do that.

6 22

(C++) Header-Only Package
by Denis Arnaud 28 Jul '11

28 Jul '11

Hello, we would like to package a C++ header-only project, namely tclap ( https://bugzilla.redhat.com/show_bug.cgi?id=683591) The relevant guideline is to be found on: https://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages The question is: 1. Should the header files go into the main package, removing the need for a -devel sub-package? The reason would be that that package is a development package only, like gcc for instance. 2. Or should the header files go into the -devel sub-package, leaving the main package almost empty (only the README, COPYING documentation would go into the main package), much like what is done for Boost header-only components? In either case, then, since header files are architecture independent, I guess that the corresponding package should be 'noarch'. However, a pkgconfig (.pc) file is delivered together with the package; and rpmlint complains that pkgconfig files should be delivered by architecture-dependent sub-packages only. Should you leave rpmlint complaining quietly? Thanks in advance Best Regards Denis

2 1

anybody understand mingw's macros?
by Farkas Levente 25 Jul '11

25 Jul '11

hi, i'm just fed up with this situation and try to debug this %mingw_cmake macros and find out why not working. since i can NOT find any kind of docs about rpm's macros! anybody know?? what and how %* works? what is the %{nil} good for? so what i find from /usr/lib/rpm/macros: --------------------------- # The configure macro should be invoked as %configure (rather than %{configure}) # because the rest of the arguments will be expanded using %*. --------------------------- now i find the in /etc/rpm/macros.mingw %mingw_cmake before the %mingw32_cmake call %* still contains the command line params. but since %{mingw32_cmake} %* called this way in stead of %mingw32_cmake %* the mingw32_cmake macro do not get the command line parameters. that's why it's not possible to give the params further. but if i rewrite the above two line than rpm macro deduction will fail (i don't know why). i try many different way tricks and trucks but none of them working. anybody has any tip or anybody can help? regards. -- Levente "Si vis pacem para bellum!"

2 1

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 20 Jul '11

20 Jul '11

Here are the latest changes to the Fedora Packaging Guidelines: --- Some rpm versions pass pathnames to the automatic filtering macros, so a section has been added to the guidelines to help packagers deal with it: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#P… --- For a while, Fedora considered mono packages to be architecture-specific, and installed assemblies to %{_libdir}. However, after discussions with upstream, we now consider mono packages to be architecture (and platform) independent. This means that mono packages should be correctly installed into the GAC in /usr/lib or installed into /usr/lib/PACKAGENAME. As a notable exception, any ELF binary libraries generated in a mono package must be correctly installed into %{_libdir}, because these files are architecture-specific. Also, even though we consider mono packages to be architecture independent, they must not be marked as "noarch". Although the assemblies are the same, the files may differ due to strings referring to the build architecture. https://fedoraproject.org/wiki/Packaging:Mono#File_Locations --- It was decided that gnome shell extension packages should have the prefix gnome-shell-extension (with no "s" on the end). https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.2… --- The section in the Fedora Packaging Guidelines concerning libexecdir has been improved and expanded: https://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir --- The Fedora Java Packaging Guidelines have been updated to reflect the latest macros for Maven 3. https://fedoraproject.org/wiki/Packaging:Java --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to Christian Krause, Aleksandar Kurtakov, Petr Pisar, Stanislav Ochotnicky, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~spot

1 0

EL5 build trouble - .desktop vendor
by Development discussions related to Fedora 19 Jul '11

19 Jul '11

My new package got build error: (only on EL5) http://koji.fedoraproject.org/koji/taskinfo?taskID=3209896 http://koji.fedoraproject.org/koji/getfile?taskID=3209896&name=build.log&of… + mkdir -p /var/tmp/tnef-1.4.8-4.1.el5-root-mockbuild//usr/share/mimelnk/application/ + desktop-file-install --dir=/var/tmp/tnef-1.4.8-4.1.el5-root-mockbuild/usr/share/mimelnk/application /builddir/build/SOURCES/vnd.ms-tnef.desktop Must specify the vendor namespace for these files with --vendor error: Bad exit status from /var/tmp/rpm-tmp.3965 (%install) RPM build errors: As I understand it, we are not supposed to include a --vendor value unless it was a pre-existing package that already had a vendor value. Is there a special case for EL5 ? If so, is it Fedora or EPEL ?

2 1

Looking for packaging advice/mentor
by Steve Jenkins 19 Jul '11

19 Jul '11

Hi, I've been lurking on this list for a while now as I experiment with packaging OpenDKIM (http://opendkim.org/) which is a milter application for milter-aware MTAs (such as Postfix and Sendmail) to sign and/or verify email with DKIM. My goal is to make packages available for Fedora, EL5 and EL6. I've got VMs set up for all those platforms (both 32- and 64-bit) and have RPMs built. I'm now looking for someone who can give me some minor guidance as to what to do next, and peek through what I've got so far and provide feedback. Thanks in advance for any assistance! SteveJ

1 0

rpmlint on Fedora and FHS
by Siem Korteweg 17 Jul '11

17 Jul '11

Hi, Before I am going to package System Configuration Collector for Fedora, I decided to run rpmlint on the existing, generic rpm of SCC. SCC consists of 25 executable shell scripts that are installed in /opt/scc/bin. Configuration files reside in /etc/opt/scc and data is stored in /var/opt/scc/. All According to the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPAC…) Fedora follows the FHS (http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout) however, rpmlint reports errors for all scripts in /opt/scc/bin: scc.noarch: E: dir-or-file-in-opt /opt/scc/bin/scc-log A file in the package is located in /opt. It's not permitted for packages to install files in this directory. Why is it not permitted for packages to install files in /opt while that is allright according to the FHS and Fedora follows FHS? regards Siem Korteweg

5 7

Automatic dependency generation: gobject-introspection
by Matthias Clasen 08 Jul '11

08 Jul '11

The OpenSuSE folks have been working on automating dependency information for use of libraries via gobject-introspection. Their generators currently cover python and javascript, you can see them here: http://bugzilla.gnome.org/show_bug.cgi?id=654156 I'm really happy to see this being pushed upstream, and it will probably land in rawhide with the next GLib release (in ~ 2 weeks) unless the packaging committee has objections. If we need to amend any packaging docs for this, let me know. Matthias

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2011