[Fedora-packaging] Source Url Guidelines

Toshio Kuratomi a.badger at gmail.com
Wed Feb 14 21:45:25 UTC 2007

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:

= 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.0.tar.bz2

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



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070214/dc787554/attachment.sig>

More information about the Fedora-packaging mailing list