| |
@@ -76,7 +76,7 @@
|
| |
Source0: foo-20070221.tar.xz
|
| |
....
|
| |
|
| |
- When pulling from revision control, please remember to use a Name-version-release compatible with the Packaging:Versioning Guidelines. In particular, check the section on Packaging:Versioning#More_complex_versioning.
|
| |
+ When pulling from revision control, please remember to use a Name-version-release compatible with the xref:Versioning.adoc[Versioning] Guidelines. In particular, check the section on xref:Versioning.adoc#_complex_versioning[Complex versioning].
|
| |
|
| |
[#when-upstream-uses-prohibited-code]
|
| |
== When Upstream uses Prohibited Code
|
| |
@@ -141,7 +141,7 @@
|
| |
|
| |
The full 40-character hash and associated git tag may be obtained by issuing the following git command:
|
| |
|
| |
- [//git-scm.com/docs/git-ls-remote git ls-remote] https://HOSTING-SERVICE/OWNER/%\{name}.git
|
| |
+ https://git-scm.com/docs/git-ls-remote[git ls-remote] \https://HOSTING-SERVICE/OWNER/%\{name}.git
|
| |
|
| |
....
|
| |
HOSTING-SERVICE: name of the service, i.e. "github.com", "bitbucket.org", "gitlab.com", etc.
|
| |
@@ -149,7 +149,7 @@
|
| |
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-scm.com/docs/git-show-ref git show-ref] command.
|
| |
+ 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 https://git-scm.com/docs/git-show-ref[git show-ref] command.
|
| |
|
| |
Once the commit hash and git tag are known, you can define them in your spec file as follows:
|
| |
|
| |
@@ -177,13 +177,13 @@
|
| |
%autosetup -n PROJECT-%{commit} [GitLab]
|
| |
....
|
| |
|
| |
- 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 Packaging:Naming#Pre-Release_packages[Pre-Release packages] for details.
|
| |
+ 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 xref:Versioning.adoc#_prerelease_versions[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: Packaging:Versioning#Snapshot_packages[Snapshot packages]. You can substitute %\{shortcommit} for the git hash in %\{checkout} in that section.
|
| |
+ 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: xref:Versioning.adoc#_snapshots[Snapshots]. You can substitute %\{shortcommit} for the git hash in %\{checkout} in that section.
|
| |
|
| |
=== Git Tags
|
| |
|
| |
- [//git-scm.com/docs/git-tag Git tags] represent a particular code point that upstream deems important; and are typically used to mark release points.
|
| |
+ https://git-scm.com/docs/git-tag[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.
|
| |
|
| |
This should fix the broken links/anchors from https://git-scm.com and also due to changes in Versioning.adoc