mirror of
https://pagure.io/fedora-docs/quick-docs.git
synced 2024-11-28 14:56:35 +00:00
Fix several warnings
This commit is contained in:
Petr Bokoc
parent
a51022557c
commit
5f4f52dc1f
3 changed files with 24 additions and 28 deletions
|
|
@ -6,13 +6,13 @@ Use this guide for information about the specific macros in a `.spec` file.
|
|||
NOTE: You can use the macros `%\{name}`, `%\{version}` and `%\{release}` to refer to the Name, Version and Release tags respectively. When you change the tag, the macros automatically update to use the new value.
|
||||
|
||||
`Name`::
|
||||
Add the base name of the package, which must match the `.spec` file name. Follow the http://fedoraproject.org/wiki/Packaging:Naming[Package Naming Guidelines] and write the file name in lower-case letters.
|
||||
Add the base name of the package, which must match the `.spec` file name. Follow the http://fedoraproject.org/wiki/Packaging:Naming[Package Naming Guidelines] and write the file name in lower-case letters.
|
||||
|
||||
`Version`::
|
||||
Add the upstream version number. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/[Package Versioning]. If the version contains tags that are non-numeric, you might need to include the non-numeric characters in the `Release` tag. If upstream uses full dates to distinguish versions, consider using version numbers of the form. For example, `yy.mm[dd]` where `2008-05-01` becomes `8.05`.
|
||||
|
||||
`Release`::
|
||||
Set the initial value to `1%\{?dist}`. Increment the number every time you release a new package for the same version of software. When a new upstream version is released, change the `Version` tag to match and reset the `Release` number to `1`. For more information, see the https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/[Versioning Guide] of the packaging guidelines.
|
||||
Set the initial value to `1%\{?dist}`. Increment the number every time you release a new package for the same version of software. When a new upstream version is released, change the `Version` tag to match and reset the `Release` number to `1`. For more information, see the https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/[Versioning Guide] of the packaging guidelines.
|
||||
|
||||
`Summary`::
|
||||
Enter a brief, one-line summary of the package. Use American English. Do not end with a period.
|
||||
|
|
@ -49,22 +49,22 @@ If you package files that are architecture-independent, for example shell script
|
|||
`BuildRoot`::
|
||||
This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in `%\{_topdir}/BUILDROOT/`.
|
||||
+
|
||||
In EPEL5, this is where files are installed during the %install process (after the %build process).
|
||||
In EPEL5, this is where files are installed during the %install process (after the %build process).
|
||||
|
||||
`BuildRequires`::
|
||||
Add a comma-separated list of packages that are required for compiling the program. Usually, this field is repeated on multiple lines. These dependencies are not automatically determined. You must include everything that the package needs to build the program.
|
||||
Add a comma-separated list of packages that are required for compiling the program. Usually, this field is repeated on multiple lines. These dependencies are not automatically determined. You must include everything that the package needs to build the program.
|
||||
+
|
||||
Verify that you have specified all the necessary build requirements by performing a "mock build" of your package. You can specify a minimum version if necessary, for example, `ocaml >= 3.08`.
|
||||
+
|
||||
If you need the file `/EGGS`, determine the package that owns it by running `rpm -qf /EGGS`.
|
||||
If you need the file `/EGGS`, determine the package that owns it by running `rpm -qf /EGGS`.
|
||||
+
|
||||
If you need the program `EGGS`, determine the package that owns it by running `rpm -qf \`which EGGS\``. Keep dependencies to a minimum. For example, use `sed` instead of `perl` if you do not need Perl, but note that some applications permanently disable functions if the associated dependency is not present; in those cases you might need to include the additional packages.
|
||||
If you need the program `EGGS`, determine the package that owns it by running `rpm -qf \`which EGGS\``. Keep dependencies to a minimum. For example, use `sed` instead of `perl` if you do not need Perl, but note that some applications permanently disable functions if the associated dependency is not present; in those cases you might need to include the additional packages.
|
||||
|
||||
`Requires`::
|
||||
Enter a comma-separate list of packages that are required when the program is installed. Note that the `BuildRequires` tag lists what is required to build the binary RPM, while the `Requires` tag lists what is required when installing and running the program; a package may be in one list or in both.
|
||||
Enter a comma-separate list of packages that are required when the program is installed. Note that the `BuildRequires` tag lists what is required to build the binary RPM, while the `Requires` tag lists what is required when installing and running the program; a package may be in one list or in both.
|
||||
|
||||
`%description`::
|
||||
Enter a longer, multi-line description of the program. Use American English. All lines must be 80 characters or less. Blank lines indicate a new paragraph.
|
||||
Enter a longer, multi-line description of the program. Use American English. All lines must be 80 characters or less. Blank lines indicate a new paragraph.
|
||||
+
|
||||
Some graphical user interface installation programs reformat paragraphs; lines that start with whitespace might be treated as preformatted text and displayed as is, normally with a fixed-width font.
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Add script commands to "prepare" the program. For example, to extract the progra
|
|||
Add script commands to compile the program and get it ready for installing. The program must come with instructions on how to do this.
|
||||
|
||||
`%install`::
|
||||
Add script commands to "install" the program. The commands must copy the files from the `BUILD` directory `%\{_builddir}` into the buildroot directory, `%\{buildroot}`.
|
||||
Add script commands to "install" the program. The commands must copy the files from the `BUILD` directory `%\{_builddir}` into the buildroot directory, `%\{buildroot}`.
|
||||
|
||||
`%check`::
|
||||
Add script commands to "test" the program. This is run after the `%install` procedure, so place it there if you have this section. Often it contains `make test` or `make check`. This is separated from `%build` so that people can skip the self-test if they desire.
|
||||
|
|
@ -84,7 +84,7 @@ Add script commands to "test" the program. This is run after the `%install` proc
|
|||
Note that this section is now redundant in Fedora and is only necessary for EPEL. Typically this contains only the following command: `rm -rf %\{buildroot}`.
|
||||
|
||||
`%files`::
|
||||
Add the list of files to be installed.
|
||||
Add the list of files to be installed.
|
||||
|
||||
`%changelog`::
|
||||
Add changes in the package. Use the format example above. Do not put software's change log here. This change log is only for the RPM.
|
||||
|
|
@ -97,9 +97,9 @@ RPM also supports the creation of several packages called subpackages from a sin
|
|||
Do *not* create a "relocatable" package; they do not add value in Fedora and make things more complicated.
|
||||
|
||||
|
||||
.Inserting comments
|
||||
.Inserting comments
|
||||
|
||||
* Insert comments with a leading `#` character, and beware of macros (beginning with `%`) that are potentially multi-line, as they are expanded first.
|
||||
* Insert comments with a leading `#` character, and beware of macros (beginning with `%`) that are potentially multi-line, as they are expanded first.
|
||||
|
||||
* When commenting out a line, double the percent signs (`%%`) of the macros appearing after the `#`.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The program and all files referenced in this guide can be found in the link:http
|
|||
user@host ~/copr-tito-quickdoc % ls
|
||||
doc LICENSE README.md requirements.txt setup.py src
|
||||
|
||||
user@host ~/copr-tito-quickdoc % ls src/hellocopr
|
||||
user@host ~/copr-tito-quickdoc % ls src/hellocopr
|
||||
colors.py hellocopr.py __init__.py
|
||||
```
|
||||
+
|
||||
|
|
@ -45,9 +45,9 @@ TIP: You can follow along with this tutorial by cloning or forking the repositor
|
|||
|
||||
Copy link:https://pagure.io/copr-tito-quickdoc/c/00963ac9339a13eefd2ab1ca42b1f72af12d3cac?branch=master[the spec file] into the project's base directory. A few changes should be made before proceeding:
|
||||
|
||||
. The values of `Version:` and `Release:` do not matter, since these will be managed by tito. It makes sense to set them to `Version: 0.0.0` and `Release: 0%{?dist}` to mark that this package hasn't been built yet.
|
||||
. The values of `Version:` and `Release:` do not matter, since these will be managed by tito. It makes sense to set them to `Version: 0.0.0` and `Release: 0%\{?dist}` to mark that this package hasn't been built yet.
|
||||
|
||||
. tito will also handle the creation of the source tarball from the git repository, so change the `Source0:` URL to the filename `%{name}-%{version}.tar.gz` & add a comment to tell users how to get the tarball
|
||||
. tito will also handle the creation of the source tarball from the git repository, so change the `Source0:` URL to the filename `%\{name}-%\{version}.tar.gz` & add a comment to tell users how to get the tarball
|
||||
|
||||
. The changelog can be left empty.
|
||||
+
|
||||
|
|
@ -55,14 +55,14 @@ Copy link:https://pagure.io/copr-tito-quickdoc/c/00963ac9339a13eefd2ab1ca42b1f72
|
|||
user@host ~/copr-tito-quickdoc % cat hellocopr.spec
|
||||
...
|
||||
Version: 0.0.0
|
||||
Release: 0%{?dist}
|
||||
...
|
||||
Release: 0%\{?dist}
|
||||
...
|
||||
# Sources can be obtained by
|
||||
# git clone https://pagure.io/copr-tito-quickdoc
|
||||
# cd copr-tito-quickdoc
|
||||
# tito build --tgz
|
||||
Source0: %{name}-%{version}.tar.gz
|
||||
...
|
||||
Source0: %\{name}-%\{version}.tar.gz
|
||||
...
|
||||
%changelog
|
||||
```
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ Wrote: /tmp/tito/hellocopr-git-11.7a6919d.tar.gz
|
|||
|
||||
Successfully built: /tmp/tito/hellocopr-0.0.0-0.git.11.7a6919d.fc32.src.rpm
|
||||
- /tmp/tito/noarch/hellocopr-0.0.0-0.git.11.7a6919d.fc32.noarch.rpm
|
||||
```
|
||||
```
|
||||
|
||||
Once we've fixed any issues with the package that might crop up, we can let tito create a package release using `tito tag`. Since we haven't set a proper version yet, we need to pass it to tito for the first tag:
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ Push to the commits & tags to the remote using `git push --follow-tags`, and we'
|
|||
.. Under _2. How to build SRPM from the source_ select _tito_
|
||||
|
||||
.. Under _3. Generic package setup_ tick the box for _Auto-rebuild_
|
||||
|
||||
|
||||
. Your package will appear in the list of packages. Hit _Rebuild_ to trigger a build. The following page lets you change any build options if necessary, we'll just use the defaults, i.e. the options we set in the previous step. Hit _Submit_ and Copr will build the package from the tito tag we created in Step 1.
|
||||
|
||||
Once the build has finished, you can test installing the package from Copr by activating your repository.
|
||||
|
|
@ -167,7 +167,7 @@ Currently, the example program has its version hardcoded at multiple places. lin
|
|||
|
||||
Commit the changes, and create a new release with tito
|
||||
```
|
||||
user@host ~/copr-tito-quickdoc % tito tag
|
||||
user@host ~/copr-tito-quickdoc % tito tag
|
||||
Creating output directory: /tmp/tito
|
||||
Tagging new version of hellocopr: 1.0.0-1 -> 1.0.1-1
|
||||
Created tag: hellocopr-1.0.1-1
|
||||
|
|
@ -241,7 +241,7 @@ To do so, the following changes need to be made to the procedure described above
|
|||
|
||||
. Instead of the unpacked sources, download & commit the source tarball you want to package to your repository
|
||||
. Instead of modifying the source directly, add any changes you need to make in the form of patch files. List these as `PatchX:` in the spec file
|
||||
. Also in the spec file, set the `Version:` back to whatever version the program is at and `Source0:` back to the tarball URL. You can use macros like `%{version}` for the latter to automatically follow version changes.
|
||||
. Also in the spec file, set the `Version:` back to whatever version the program is at and `Source0:` back to the tarball URL. You can use macros like `%\{version}` for the latter to automatically follow version changes.
|
||||
. Modify tito's `.tito/tito.props` to, one, not try to build a source tarball and two, bump the `Release:` instead of the `Version:` when tagging
|
||||
+
|
||||
```
|
||||
|
|
@ -252,6 +252,6 @@ tagger = tito.tagger.ReleaseTagger
|
|||
+
|
||||
. Don't do any tito templating
|
||||
|
||||
The rest of the procedure stays the same. If you make changes to the package without changing the source, you can just tag a new release with tito. If you do update the source tarball, you need to update the `Version:` field and reset `Release:` to `0%{?dist}` before tagging.
|
||||
The rest of the procedure stays the same. If you make changes to the package without changing the source, you can just tag a new release with tito. If you do update the source tarball, you need to update the `Version:` field and reset `Release:` to `0%\{?dist}` before tagging.
|
||||
|
||||
TIP: The tarball-adapted version of the project can be found in the `https://pagure.io/copr-tito-quickdoc/tree/foreign-sources[foreign-sources]` branch of the git repo.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@
|
|||
// Save the context of the assembly that is including this one.
|
||||
// This is necessary for including assemblies in assemblies.
|
||||
// See also the complementary step on the last line of this file.
|
||||
:parent-context: {context}
|
||||
// Base the file name and the ID on the assembly title. For example:
|
||||
// * file name: my-assembly-a.adoc
|
||||
// * ID: [id='my-assembly-a']
|
||||
|
|
@ -71,6 +70,3 @@ include::{partialsdir}/ref_frequently-asked-questions_-installing-fedora-on-a-ra
|
|||
** link:https://ask.fedoraproject.org/[Ask Fedora]
|
||||
** link:https://lists.fedoraproject.org/admin/lists/arm%40lists.fedoraproject.org/[Fedora ARM mailing list]
|
||||
** irc://irc.freenode.net/#fedora-arm[IRC via the #fedora-arm channel on Freenode]
|
||||
|
||||
// Restore the context to what it was before this assembly.
|
||||
:context: {parent-context}
|
||||
|
|
|
|||
Loading…
Reference in a new issue