packaging November 2009

packaging@lists.fedoraproject.org

37 participants
22 discussions

Revised Emacs add-on guidelines
by Jonathan Underwood 14 Dec '09

14 Dec '09

Dear All, We've recently added some macro definitions under /etc/rpm/macros.[x]emacs to simplify add on packaging for (X)Emacs. The main point being that we no longer use the pkg-config way of finding directory locations etc at add-on package build time, which removes all the boiler plate stufff that was being added to every add on package. A new draft of the guidelines is here: https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised Comments welcome! Best wishes, Jonathan

3 9

Fedora Packaging Committee Meeting - Nov 24, 2009 - 1600 UTC
by Tom Callaway 05 Dec '09

05 Dec '09

The Fedora Packaging Committee will have its next meeting on Tuesday, November 24, 2009 @ 1600 UTC, in #fedora-meeting. Here is the tentative agenda: * pkgconfig autorequires: https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires * Revised Emacs add-on guidelines: https://fedoraproject.org/wiki/PackagingDrafts/EmacsPackagingRevised * man-pages guidelines: https://fedoraproject.org/wiki/User:Varekova/man-pages/missing-man-pages * Python3 Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/Python3 A reminder: If you have something that you want to get onto the FPC's agenda, the procedure is documented here: https://fedoraproject.org/wiki/Packaging:Committee#Guideline_Change_Procedu… Thanks, ~spot

8 17

disttag doesn't work
by Martial Paupe 23 Nov '09

23 Nov '09

hello, I'm building packages and I want to use disttag as referred at this page. https://fedoraproject.org/wiki/Packaging:DistTag as a result the package is named as is packagename-1.0.0-1.noarch.rpm instead of packagename-1.0.0-1el5.noarch.rpm here the head of my specfile. Name: packagename Version: 1.0.0 Release: 1%{?dist} Summary: some text Group: application License: Propriatory URL: http://somewhere.domain.com Source0: %{name}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch Conflicts: libgcj %description more text in these area %package binary Summary: packagename binary and library Group: System %if 0%{?rhel} >= 4 || 0%{?rhel} Requires: jre else Requires: java-1.6.0-openjdk Obsoletes: jre %endif Obsoletes: packagename-stack ...... ...... ...... ...... What I do wrong? Thanks for your help

5 6

packaging Emacs-goodies - local mock build hangs running /usr/bin/idn
by Arun SAG 23 Nov '09

23 Nov '09

Hi, I am trying to package emacs goodies for fedora, for some weird reason local mock build hangs running '/usr/bin/idn --quiet --idna-to-ascii --usestd3asciirules' (koji build was successful) . Any idea on how to fix this? Bugzilla url: https://bugzilla.redhat.com/show_bug.cgi?id=530090#c26 cheers, Arun S.A.G

1 0

Re: How to patch against strip?
by Tareq Al Jurf 22 Nov '09

22 Nov '09

> > Richard, I think he's just asking for help about where to look for > avoid stripping his binaries _before_ RPM strips them and creates the > debuginfo stuff. > > He's probably getting empty debuginfo packages at the moment and wants > to fix the build. > > Tareq, is this the situation you're in? > Omg!! That's that's exactly my problem :) -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf(a)fedoraproject.org

5 4

Naming guidelines: Parents & children
by Christoph Wickert 22 Nov '09

22 Nov '09

Hi, I have packaged gtkhash [1]. The latest version comes with a nautilus extension that I'd like to package separately so gtkhash can be installed without GNOME/nautilus. I wonder what the proper name for the nautilus extension package is. gtkhash-nautilus-extension? gtkhash-nautilus? nautilus-gtkhash? The naming guidelines read [2]: "If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora package without being useful on its own, its name should reflect this fact." The extension is cannot be used without ether nautilus or gtkhash, so this wont help us to make a decision. From the "enhancement" point of view I'd say it's nautilus that gets enhanced, so the proper name would be nautilus-gtkhash. On the other hand gtkhash-nautilus(-extension) makes it easier to find the package in bugzilla. So the question is: What is the "parent"? The source package or the one that gets enhanced? This affects other nautilus packages as well. Currently we have: Package (Source package) * brasero-nautilus (brasero) * gnome-mplayer-nautilus (gnome-mplayer from "that other repo") * nautilus-actions (nautilus-actions) * nautilus-beesu-manager (beesu) * nautilus-bzr (bzr) * nautilus-extensions (nautilus) * nautilus-image-converter (no subpackage) * nautilus-open-terminal (nautilus-open-terminal) * nautilus-phatch (phatch) * nautilus-python (nautilus-python) * nautilus-search-tool (nautilus-search-tool) * nautilus-sendto (nautilus-sendto) * nautilus-sound-converter (nautilus-sound-converter) * tortoisehg-nautilus (tortoisehg) * totem-nautilus (totem) I think we should tighten the naming guidelines a little to make our package names more consistent, especially gnome-panel applets: Package (Upstream source name) * autobuild-applet (autobuild-applet) * contact-lookup-applet (contact-lookup-applet) * deskbar-applet (deskbar-applet) * file-browser-applet (file-browser-applet) * gdm-user-switch-applet (gdm) * gnome-applet-alarm-clock (alarmclock) * gnome-applet-bubblemon (bubblemon) * gnome-applet-cpufire (cpufire_applet) * gnome-applet-globalmenu (subpackage of gnome-globalmenu) * gnome-applet-grandr (grandr_applet) * gnome-applet-jalali-calendar (jalali-calendar) * gnome-applet-music (music-applet) * gnome-applet-netspeed (netspeed_applet) * gnome-applets * gnome-applet-sensors (sensors-applet) * gnome-applet-sshmenu (sshmenu) * gnome-applet-timer (timerapplet) * gnome-applet-window-picker (window-picker-applet) * hamster-applet (subpackage of hamster) * lock-keys-applet (lock-keys-applet) * resapplet (not an applet but a tray icon) * zapplet (not an applet but a tray icon) Proposal: 1. Leave tray icons as is. They can be used in all desktops. 2. Rename all gnome-panel applets to gnome-applet-* 3. Packages that don't match the upstream name get a "Provides: <upstream-name> = %{version}" so they can be installed more easy Instead of 2. we could prefix all applets with "gnome-" and leave the upstream names intact. This is what we currently have in Xfce, upsteam has a consistent naming of their plugins, all are named xfce4-*-plugin. What do you think is best? Regards, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=540328 [2] http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28…

1 0

code vs. content
by Ralf Corsepius 22 Nov '09

22 Nov '09

Hi, There is a package (london pictures) under review[1], which I consider to be a corner case wrt. "Code vs. content"[2]. The problem I have with this package providing a precedence of how to circumvent Fedora's regulations/guidelines etc. to use Fedora as means to distribute "mere content". In other words, I fear this package is a precedence to opens a can of worms for content packages. What to do about this package and about this issue in general? My gut feeling is, Fedora should refine their "code vs. content" rules, otherwise we will soon Fedora being filled up with arbitrary "photo/sound/video collections" disguised as "backgrounds", "sound fonts", etc. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=538557 [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content

9 23

Proposal: support multiple Python minor versions
by David Malcolm 20 Nov '09

20 Nov '09

Proposal: support multiple Python minor version, as one instance of a generalized way of supporting variant stacks. Currently we support a single version of Python; we pick a specific minor-release of Python (currently "2.6", in fact 2.6.4 in rawhide), and all modules are assumed to be for that "2.MINOR" version of Python. We plan to extend this further in Fedora 13, with the idea that there's additionally a specific minor-release of Python 3 (currently "3.1", in fact 3.1.1), and all python3-foo rpms are assumed to be for that "3.MINOR" version of Python [1] Some people want more: they want additional minor versions: for example, when we want to upgrade "python" to mean "python 2.7", we will rebuild all our RPMs for 2.7, but some users may have code written to 2.6 that they don't want to bother porting. This makes more sense in an EPEL context: in EPEL5 we have the system python as "2.4", but many people want a "2.6" stack, others want "2.3", 2.5", "3.1", etc etc. There are ways of doing this within the current Fedora/EPEL packaging framework, but it would lead to an explosion of specfiles and CVS directories. I dislike this: I think of specfiles as human-readable source code for driving a reproducable build; I hate having many almost-identical copies of a source file. I had an idea for how this could be done whilst minimizing "specfile explosion"; it allows for the generation of parallel families of RPMs from one specfile, moving the complexity from the individual packager into the build system, and onto release-engineering (sorry Jesse!) - and eating up more disk space, build time, etc. Caveat: I haven't looked into the details of whether Koji, package CVS, and Makfile.common can actually cope with some of the ideas here, and I've not tested the specifics of the rpm macros; the proposal is independent of but compatible with the Python3 feature (I think). PROPOSAL: - Introduce the following new packaging macros: - "pyprefix": - defined as "python" for the system build of python - defined as "pythonMN" for a build of python-M.N e.g. "python26" for "python-2.6" - for use in the names of packages - "pysuffix": - defined as the empty string for the system build of python - defined as "-M.N" for builds of python-M.N e.g "-32" for "python-3.2" - for use in /usr/bin when giving alternative versions of tools e.g. "/usr/bin/pydoc-3.2" to be the python-3.2 version of "pydoc" - Within python-foo module specfiles and the python module packaging guidelines: - Add default definitions of the macros: %{!?pyprefix: %global pyprefix python} %{!?pysuffix: %global pysuffix} - Change: Name: python-foo to: Name: %{pyprefix}-foo and similarly for all dependencies, so that e.g.: BuildRequires: python-devel python-setuptools becomes: BuildRequires: %{pyprefix}-devel %{pyprefix}-setuptools - In %install, move scripts if necessary (to allow parallel-installability), adding: for script in foo bar baz ; do mv %{buildroot}/usr/bin/$script mv %{buildroot}/usr/bin/$script-%{pysuffix} done This gives us a single specfile, which can be used with different definitions of these macros to give multiple builds, leading to multiple SRPMs (the package changes name for the alternative builds). Where do these macros gets expanded out? Say in Koji's "dist-f14" we have python = python2.7 and python3 = python3.2, and we want to support alternative python stacks. Then for the dist-f14 build tags, introduce multiple new tags: dist-f14-altbuild-python23 dist-f14-altbuild-python24 dist-f14-altbuild-python25 dist-f14-altbuild-python26 dist-f14-altbuild-python30 dist-f14-altbuild-python31 Each of these "altbuild" tags inherit from the main dist-f14 build tag, adding a single RPM: "rpm-altbuild-macros-pythonMN-0.1-1.fc14" e.g. "rpm-altbuild-macros-python26-0.1-1.fc14" which contains a single file: /etc/rpm/altbuild-python26.macros (changing the version as appropriate), defining the macros: %global pyprefix python26 %global pysuffix -2.6 %global __python /usr/bin/python2.6 (need to ensure this last one actually gets used; need to move the define from rpm to python-devel) These Koji tags are in addition to the regular one ("dist-f14"), in which "python" and "python3" have their default meanings. All of these tags would deposit their built packages into dist-f14 Similarly, for EPEL5, extend "dist-5E-epel-testing-candidate", introducing multiple child tags: dist-5E-epel-testing-candidate-altbuild-python23 dist-5E-epel-testing-candidate-altbuild-python25 dist-5E-epel-testing-candidate-altbuild-python26 dist-5E-epel-testing-candidate-altbuild-python27 dist-5E-epel-testing-candidate-altbuild-python30 dist-5E-epel-testing-candidate-altbuild-python31 all of which would deposit their built packages into dist-5E-epel-testing-candidate For packaging CVS, add a new, optional file to a dist CVS subdirectory, "build-variability". So for package "python-foo", "python-foo/EL-5/build-variability" might contain these lines: dist-5E-epel-testing-candidate-altbuild-python23 dist-5E-epel-testing-candidate # 2.4 is the default in EPEL5 dist-5E-epel-testing-candidate-altbuild-python25 dist-5E-epel-testing-candidate-altbuild-python26 dist-5E-epel-testing-candidate-altbuild-python27 dist-5E-epel-testing-candidate-altbuild-python30 dist-5E-epel-testing-candidate-altbuild-python31 If "build-variability" is present, it would change the meaning of "make build": instead of triggering a job that does a single build into "dist-5E-epel-testing-candidate", it would create a job that builds into all of the build tags listed in the file. If any of these builds fail, the whole build fails, and no RPMs reach he destination tag. If a particular module only works with some minor-releases (perhaps it doesn't work with python 3 yet, or needs python>=2.4 etc), then the file would be edited appropriately. I have no great love for "build-variability" as a name. Caveat: I'm handwaving here; I haven't looked into the details of what it would take on the Koji side and to Makefile.common We'd be going from two dimensions of variability: - build architecture (i386, x86_64 etc; currently expressed internally in Koji) - OS release (devel, F12, EPEL5 etc) where we have a CVS directory per OS-release (one dimension) up to three dimensions of variability: - build architecture (i386, x86_64 etc) - OS release (devel, F12, EPEL5 etc) - Python minor release (2.3, 2.4, 2.5, 2.6, etc) whilst keeping just one CVS directory per OS-release; the package maintainer only has to edit a single specfile, and can attempt to ensure that it builds across all minor-releases he/she cares about; release-engineering would have a fair bit of extra complexity to deal with though. It may be necessary to add extra macros to the altbuild macro files so that specfiles can somehow easily conditionalize the build for altbuild variants matching some criteria (e.g. on altbuild for 2.6 and above, need this extra Patch3") I've tried to structure this so it can be reused for other language runtimes where we might want to support multiple versions; perhaps the Perl SIG would want a similar family of "altbuild" macros (I'm not a perl person so maybe I'm missing something here). The proposal only exposes a single extra dimension of variability; higher dimensionality seems to lead to combinatorial explosion (e.g sqlalchemy versions). It also assumes (perhaps overoptimistically) than these other language runtimes are independent, so that we never have collisions where e.g. something wants to consume both multiple python stacks and multiple perl stacks. This assumption fails for the case of e.g. multiple parallel versions of say postgres or httpd, etc where you might also want multiple versions of python, and multiple mod_pythons M * N combinatorial explosion [2] Thoughts? Total insanity? Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 [2] so for e.g. python-psycopg2 you could unroll a 2-dimensional variability table into the file in dist-CVS, and into Koji tags, expressing all combinations of the postgres libs and of the python minor version; similarly for shipping multiple httpd versions versus python versions for mod_python. This many-dimensional approach quickly gets too complex to deal with, I think.

3 2

How to patch against strip?
by Tareq Al Jurf 20 Nov '09

20 Nov '09

I'm building a package Probably the package’s ‘make install’ function invokes ‘strip’ on the binaries it produces. How do i patch the Makefile to not do that. Thanks in Advance -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf(a)fedoraproject.org

4 3

Obsoletes in renamed rubygem a blocker?
by Jeroen van Meeuwen 20 Nov '09

20 Nov '09

Hi there, I've had rubygem-net-ldap packaged and deployed throughout my company, e.g. on all development workstations and on all dev/test/beta/prod servers. My company is letting me package this ruby gem for Fedora as well, along with a bunch of other ruby gems. During the review[1], M. Tasaka suggested the name should have been rubygem-ruby-net-ldap instead, and so I added an Obsoletes header for rubygem-net-ldap. This is now a blocker for M. Tasaka to approve the package, but if and when I remove it, and the new package is in Fedora I have to manually update all of approximately 40-50 development workstations and Fedora servers. I just need that Obsoletes header to be in the RPM, and that RPM with that header to be in the updates repository once. More details are in the review request[1], and I would appreciate your opinion on this Obsoletes header becoming a blocker. Kind regards, Jeroen van Meeuwen -kanarip [1] https://bugzilla.redhat.com/show_bug.cgi?id=532309

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2009