From Fedora Project Wiki

Already ratified
The final and ratified version of this draft is available at Packaging/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:



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:

Source0: foo-20070221.tar.gz

When pulling from revision control, please remember to use a Name-version-release compatible with the [wiki:Self:Packaging/NamingGuidelines#PackageVersion Version] and [wiki:Self:Packaging/NamingGuidelines#PackageRelease Release] Guidelines. In particular, check the section on [wiki:Self:Packaging/NamingGuidelines#SnapshotPackages 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



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:

Source0: system-config-foo-1.0.tar.gz

For packages hosted on sourceforge, use


changing ".tar.gz" to whatever matches the upstream distribution. Note that we are using instead of an arbitrarily chosen mirror. You may use the package name/package version instead of the %{name} and %{version} macros, of course.

Some comments on this from HansdeGoede: (or which is a shorter alias but otherwise exactly the same) will do a dumb redirect to a mirror, I say a dumb redirect as it will take the file location after the hostname as is without any checking and then postfix this to the choosen mirrors hostname to get the URL to redirect to.

Now most mirrors will work fine with{name}/xxx, but some mirrors will only work with{name}/xxx, notice that this longer version will also work on mirrors which accept{name}/xxx, as they seem to have a symlink to / called sourceforge :)

Thus the above is wrong as it won't work with all mirrors. Correct would be:


Or even better as this makes things fit easily into 80 chars lenght:


Now I don't feel its my place to go make random changes hence this comment feel free to update the draft and delete this :)

Using %{version}

Using %{version} in the SourceX: makes it easier for you to bump the version of a package, because most of the time you do not to edit SourceX: when editing the specfile for the new package.