Referencing Source (original) (raw)

If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages.

Git web-based hosting services provide a mechanism to create tarballs on demand, either from a specific commit revision, or from a specific tag. If the upstream does not create tarballs for releases, you can use this mechanism to produce them.

The full 40-character hash and associated git tag may be obtained by issuing the following git command:

git ls-remote https://HOSTING-SERVICE/OWNER/%{name}.git

HOSTING-SERVICE: name of the service, i.e. "github.com", "bitbucket.org", "gitlab.com", etc. OWNER: username for the repository owner PROJECT: upstream project name (if it's identical to the package name, use %{name} instead)

You may also obtain the 40-character hash and associated git tag via the web-interface of the HOSTING-SERVICE, or by cloning the repository and issuing the git show-ref command.

Once the commit hash and git tag are known, you can define them in your spec file as follows:

%global commit 40-CHARACTER-HASH-VALUE %global gittag GIT-TAG %global shortcommit %(c=%{commit}; echo ${c:0:7}) [GitHub] %global shortcommit %(c=%{commit}; echo ${c:0:11}) [Bitbucket] %global shortcommit %(c=%{commit}; echo ${c:0:7}) [GitLab] %global shortcommit %(c=%{commit}; echo ${c:0:8}) [Sourcehut]

Commit Revision

For the source tarball, you can use the following syntax:

Source: https://github.com/OWNER/PROJECT/archive/%{commit}/%{name}-%{shortcommit}.tar.gz [GitHub] Source: https://bitbucket.org/OWNER/PROJECT/get/%{commit}.tar.gz#/%{name}-%{shortcommit}.tar.gz [BitBucket] Source: https://gitlab.com/OWNER/PROJECT/-/archive/%{commit}/%{name}-%{shortcommit}.tar.gz [GitLab] Source: https://git.sr.ht/~OWNER/PROJECT/archive/%{shortcommit}.tar.gz#/PROJECT-%{shortcommit}.tar.gz [Sourcehut] ...

%prep %autosetup -n PROJECT-%{commit} [GitHub] %autosetup -n OWNER-PROJECT-%{shortcommit} [BitBucket] %autosetup -n PROJECT-%{commit} [GitLab] %autosetup -n PROJECT-%{shortcommit} [Sourcehut]

If the release corresponds to a git tag with a sane numeric version, you must use that version to populate the Version: tag in the spec file. If it does not, look at the source code to see if a version is indicated there, and use that value. If no numeric version is indicated in the code, you may set Version to 0, and treat the package as a "pre-release" package (and make use of the %{shortcommit} macro). See Prerelease versions for details.

Alternately, if you are using a specific revision that is either a pre-release revision or a post-release revision, you must follow the "snapshot" guidelines. They are documented here: Snapshots. You can substitute %{shortcommit} for the git hash in %{checkout} in that section.

Git Tags

Git tags represent a particular code point that upstream deems important; and are typically used to mark release points.

Bitbucket uses the %{shortcommit} identifier as part of the archive directory structure; regardless of whether you use git tag or Commit Revision to retrieve it. This is shown in the %prep section example.

For the source tarball, you can use the following syntax:

Source: https://github.com/OWNER/PROJECT/archive/%{gittag}/%{name}-%{version}.tar.gz [GitHub] Source: https://bitbucket.org/OWNER/PROJECT/get/%{gittag}.tar.gz#/%{name}-%{version}.tar.gz [BitBucket] Source: https://gitlab.com/OWNER/PROJECT/-/archive/%{gittag}/%{name}-%{version}.tar.gz [GitLab] Source: https://git.sr.ht/~OWNER/PROJECT/archive/%{version}.tar.gz#/PROJECT-%{version}.tar.gz [Sourcehut] ...

%prep %autosetup -n PROJECT-%{gittag} [GitHub] %autosetup -n OWNER-PROJECT-%{shortcommit} [BitBucket] %autosetup -n PROJECT-%{version} [GitLab] %autosetup -n PROJECT-%{version} [Sourcehut]