packaging February 2007

packaging@lists.fedoraproject.org

40 participants
27 discussions

Please update PHP PECL Guidelines : [Fwd: [SECURITY] Fedora Core 6 Update: php-5.1.6-3.4.fc6]
by Remi Collet 24 Feb '07

24 Feb '07

--------------------------------------------------------------------- Fedora Update Notification FEDORA-2007-261 2007-02-20 --------------------------------------------------------------------- Product : Fedora Core 6 Name : php Version : 5.1.6 Release : 3.4.fc6 .... --------------------------------------------------------------------- * Fri Feb 16 2007 Joe Orton <jorton(a)redhat.com> 5.1.6-3.4.fc6 ... - add php(api), php(zend-abi) provides (#221302) As php(api), php(zend-abi) are now provided on FC >= 6, i think http://fedoraproject.org/wiki/Packaging/PHP#head-435fc0b2b6fa2e807e89b72025… should be update to use this new provides (more robust to detect PHP ABI changes) I've just push php-pecl-zip update which use this : %if %{?php_zend_api}0 # Provides by new php-common on FC >= 6 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else # Old Provides Requires: php-api = %{php_apiver} %endif Regards, Remi

1 1

Use of vendor in .desktop files
by Todd Zullinger 21 Feb '07

21 Feb '07

Has the use of vendor in .desktop files been changed recently? The guidelines currently say "If upstream uses <vendor_id>, leave it intact, otherwise use fedora as <vendor_id>." This is what I'm doing in my package. I see that there are some proposed changes to the desktop files section in PackagingDrafts/DesktopFiles, but the use of vendor is unchanged in that draft. I also don't see anything in the IRClogs nor do I recall reading anything on this list. I ask because it's come up in a review and I'd just like to be sure that I haven't missed a change (and so I'll have a clear and definitive answer to refer to in the review [#228425]). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== So live that you can look any man in the eye and tell him to go to hell. -- Anonymous

2 2

Source Url Guidelines
by Toshio Kuratomi 15 Feb '07

15 Feb '07

Hey all, Here's my first draft of a SourceURL guideline. This tries to encapsulate current practices but a few new things had to be added related to SRPMs where no upstream source exists. This draft will probably need some touching up as I whipped it up pretty quickly but hopefully it captures the spirit of what we're trying to achieve. The latest version is available at: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl ''' = Referencing Source = One of the design goals of rpm is to cleanly separate upstream source from vendor modifications. For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream. To help reviewers and QA scripts verify this, the packager needs to indicate where a reviewer can find the source that was used to make the rpm. The most common case is where upstream distributes source as a tar.gz, tar.bz2 or zip archive that we can download from an upstream website. In these cases you must use a full URL to the package in the SourceX: line. For example:: {{{ Source0: http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Source0: http://ftp.gnome.org/pub/GNOME/sources/gnome-common/2.12/gnome-common-2.12.… }}} There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:. Here are some specific examples: == Using Revision Control == In some cases you may want to pull sources from upstream's revision control system because there have been many changes since the last release and you think that a tarball that you generate from there will more accurately show how the package relates to upstream's development. Here's how you can use a comment to show where the source came from:: {{{ # The source for this package was pulled from upstream's cvs. Use the # following commands to generate the tarball: # svn export -r 250 http://www.foo.org/svn/foo/trunk foo-20070221 # tar -czvf foo-20070221.tar.gz foo-20070221 Source0: foo-20070221.tar.gz }}} When pulling from revision control, please remember to use a Name-version-release compatible with the release guidelines. In particular, check the section on Naming Snapshots. == When Upstream uses Prohibited Code == Some upstream packages include patents or trademarks that we are not allowed to ship even as source code. In these cases you have to modify the source tarball to remove this code before you even upload it to the build system. Here's an example of using a script to document how you went from the upstream tarball to the one included in the package: From the spec: {{{ Source0: libfoo-1.0-nopatents.tar.gz # libfoo contains patented code that we cannot ship. Therefore we use # this script to remove the patented code before shipping it. # Download the upstream tarball and invoke this script while in the # tarball's directory: # ./generate-tarball.sh 1.0 Source1: generate-tarball.sh }}} generate-tarball.sh: {{{ #!/bin/sh VERSION=$1 tar -xzvf libfoo-$VERSION.tar.gz rm libfoo-$VERSION/src/patentedcodec.c sed -i -e 's/patentedcodec.c//' libfoo-$VERSION/src/Makefile tar -czvf libfoo-$VERSION-nopatents.tar.gz }}} == We are Upstream == For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: {{{ # This is a Red Hat maintained package which is specific to # our distribution. Thus the source is only available from # within this srpm. Source0: system-config-foo-1.0.tar.gz }}} ''' -Toshio

9 22

Draft: Perl packages don't need -devel for .h headers
by Tom Callaway 14 Feb '07

14 Feb '07

Since perl is special, perl packages are exempt from the requirement for -devel packages for .h header files. This has been the status quo for some time, but never explicitly stated. Take a second and vote on this please. Thanks, ~spot

10 26

BuildRoot and mktemp -d
by Ville Skyttä 13 Feb '07

13 Feb '07

On Tuesday 13 February 2007, you wrote: > > The following page has been changed by TomCallaway: > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo [...] > + ||ratify ||New Required Buildroot||[wiki:Self:TomCallaway > spot]||2007-02-13||Change required buildroot for new packages to %(mktemp > -d %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) (old packages/core > merge packages using old buildroot are grandfathered)|| Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp dirs will start to appear in %{_tmppath}. For example "rpm -q --specfile foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans them up (no, tmpwatch doesn't count) - we probably don't want that. One way to avoid it is mktemp -ud, but it's more racy than plain -d. I think -ud would be a better choice nevertheless.

6 7

Firmware packaging
by Bill Nottingham 13 Feb '07

13 Feb '07

We did some discussion at the board meeting last week about firmware images, such as that used for ipw2200. The decision was made that we're OK with shipping these firmware images based on the guidelines currently in the packaging guidelines: * The files are non-executable (note: this means that the files cannot run on their own, not that they are just chmod -x) * The files are not libraries. * The files are standalone, not embedded in executable or library code. * Explicit permission is given by the owner to freely redistribute without restrictions (this permission must be included, in "writing", with the files in the packaging) * The files must be necessary for the functionality of open source code being included in Fedora. However, these packages will not be (in many cases) fully open source - while they're distributable, the licenses do not permit modification, reverse engineering, etc. So we want to make sure that these packages are easily queryable/findable. Proposal: 1) Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag) 2) The License tag for any firmware that disallows modification should be set to: "Redistributable firmware, no modification permitted" Comments? Note that there is other firmware (zd* USB devices, etc) that is under GPL and wouldn't need this license tag. Bill

11 16

Missing tomorrow's meeting
by Ville Skyttä 13 Feb '07

13 Feb '07

Hello, Looks like I'll be missing tomorrow's packaging committee meeting.

2 1

Too many exceptions
by Axel Thimm 09 Feb '07

09 Feb '07

Currently the guidelines are bloated with proposals for exceptions. How about we keep the guidelines clean and simple, and either relax their status from commandments to guidelines, or setup an Anti-guidelines wiki page where temporary exceptions are listed. I'm concerned that new packagers, or packagers revisiting the guidelines will need to filter the proper guidelines out of the exceptions, or mistake the exceptions for rules. -- Axel.Thimm at ATrpms.net

2 1

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

Re: Development/Libraries/Java Group?
by Fernando Nasser 08 Feb '07

08 Feb '07

Anyone knows what was the resolution of this? Is Development/Libraries/Java OK or not? Regards, Fernando Anthony Green wrote: > On Thu, 2006-07-20 at 18:24 -0500, Jason L Tibbitts III wrote: >> Back to reality, it seems to me to be imminently reasonable that Java >> should have its own package group because there are a quantity of >> packages associated with it, but to argue that Java alone deserves >> such treatment while other languages in the same situation don't >> because they're not "subsystems" seems, well, odd. > > I agree. I think we should allow for Development/Libraries/[LANGUAGE] > because... > > - Groups are used to make browsing packages simpler > - People browsing Development/Libraries are programmers > - Programmers are typically looking for language specific libraries > > So, my proposal it to let packagers extend Development/Libraries with > a /[LANGUAGE] (Perl, Python, Java, C++, Lisp, etc, but not C, which can > default to Development/Libraries). > > AG >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2007