Remove Creating RPM Packages
The content in page "Creating RPM Packages" has been subsumed under "Package Tutorial: GNU Hello" in the Package Maintainer Docs. Thus, the page is removed and all references to it are pointed to the Packaging Tutorial. "Creating RPM Packages" has one subpage, which is moved to a top-level page. In a separate commit for the Package Maintainer Docs, the url of "Creating RPM Packages" will be listed as an alias of the "Package Tutorial" so that external links will keep working.
This commit is contained in:
Otto Urpelainen
parent
f597fad0b8
commit
0271db9b23
8 changed files with 6 additions and 351 deletions
|
|
@ -95,8 +95,7 @@
|
|||
//FIXME * xref:uefi-with-qemu.adoc[Using UEFI with QEMU]
|
||||
|
||||
|
||||
* xref:creating-rpm-packages.adoc[Creating RPM packages]
|
||||
** xref:publish-rpm-on-copr.adoc[Publishing your software on Copr]
|
||||
* xref:publish-rpm-on-copr.adoc[Publishing your software on Copr]
|
||||
|
||||
* Databases
|
||||
** xref:postgresql.adoc[PostgreSQL]
|
||||
|
|
|
|||
|
|
@ -1,49 +0,0 @@
|
|||
[[rpm-packaging-overview]]
|
||||
= RPM Packaging Overview
|
||||
|
||||
Use this guide to create RPM packages and `.spec` files. Despite the focus on Fedora, you can apply much of this document to other RPM-based distributions.
|
||||
|
||||
NOTE: For a general-purpose RPM building guide for packagers on Fedora, CentOS, and Red Hat Enterprise Linux, see the https://rpm-packaging-guide.github.io/[RPM Packaging Guide].
|
||||
|
||||
For more information about packaging guidelines, see the following guides:
|
||||
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines]
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/[Licensing Guidelines]
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines]
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/[Dist Tag Guidelines]
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Package Review Guidelines]
|
||||
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/[Recipes for RPM scriptlets]
|
||||
|
||||
|
||||
If you plan to submit a package to the official Fedora repository, follow the procedure in https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/[Joining the Package Maintainers].
|
||||
|
||||
Before you begin, select a text editor that you want to use, and ensure that you understand the following terminology.
|
||||
|
||||
[[rpm-terminology]]
|
||||
== RPM terminology
|
||||
|
||||
RPM::
|
||||
The package manager used by Fedora, Red Hat Enterprise Linux, Mageia, OpenSUSE and others. Originally RPM stood for "Red Hat Package Manager" but now it is a recursive acronym "RPM Package Manager".
|
||||
|
||||
spec file::
|
||||
A plain text file that contains information about a package and instructions that RPM uses for compiling the package's software. To name the file, use the name of the package with the file extension `.spec`.
|
||||
|
||||
tag::
|
||||
A string, generally capitalized and followed by a colon, which appears at the top of the `.spec` file to provide some important data about the RPM, such as `Name:`, `Version:` or `Summary:`.
|
||||
|
||||
section::
|
||||
A segment of the `.spec` file that tells RPM how to perform some portion of the package construction process. Many, but not all, sections contain code that is simply passed to the shell, though RPM has significant flexibility around this that is outside of the scope of this document.
|
||||
|
||||
section header::
|
||||
A short string, starting with `%` at the beginning of a line, which introduces a section. Examples include `%description`, `%prep` and `%files`.
|
||||
|
||||
macro::
|
||||
A short string, always prefixed by `%` and generally surrounded by curly brackets `{}` which RPM converts to a different and usually longer string. Some macros can take arguments and some arguments are quite complex. Some macros are provided by RPM, some are part of https://apps.fedoraproject.org/packages/redhat-rpm-config[redhat-rpm-config] and https://apps.fedoraproject.org/packages/fedora-rpm-macros[fedora-rpm-macros] packages, but many other packages also provide macros. You can run `rpm --showrc` to view all of the macros currently available on your system, but you do not need to run most of the macros you see there.
|
||||
+
|
||||
For a full list of guidelines related to macros, see https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/[Macros] in the Packaging Guidelines.
|
||||
|
||||
mock::
|
||||
A system for building RPMs locally within your own Fedora installation. This avoids the need to install a full set of build dependencies on your operating system installation, and allows you to build packages for different Fedora releases.
|
||||
|
||||
koji::
|
||||
The main Fedora build system: https://koji.fedoraproject.org[1].
|
||||
|
|
@ -1,106 +0,0 @@
|
|||
[[con_rpm-spec-file-overview]]
|
||||
= RPM spec file overview
|
||||
|
||||
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 https://docs.fedoraproject.org/en-US/packaging-guidelines/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.
|
||||
|
||||
`Summary`::
|
||||
Enter a brief, one-line summary of the package. Use American English. Do not end with a period.
|
||||
|
||||
`Group`::
|
||||
This tag is deprecated since Fedora 17. See https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html[Spec
|
||||
File Reference Preamble]
|
||||
|
||||
`License`::
|
||||
Enter an open source software license. Do not use the old Copyright tag. Use a standard abbreviation, for example, `GPLv2+` and be specific. For example, use `GPLv2+` for GPL version 2 or greater rather than `GPL` or `GPLv2` where it's true. For more information, see the https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/[Licensing Guidelines].
|
||||
+
|
||||
You can list multiple licenses by combining them with `and` and `or` (e.g. `GPLv2 and BSD`).
|
||||
|
||||
`URL`::
|
||||
The full URL for more information about the program. For example, the project website.
|
||||
+
|
||||
NOTE: Do not add a link to the original source code. Add the link to the source code to the `Source0` tag.
|
||||
|
||||
`Source0`::
|
||||
Enter the full URL for the compressed archive that contains the original, pristine source code, as upstream released it. "`Source`" is synonymous with "`Source0`".
|
||||
+
|
||||
The full URL basename is used when looking in the `SOURCES` directory. If possible, embed `%\{name}` and `%\{version}`, so that changes to the go to the right place. Preserve the timestamps when downloading source files. For more information, see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_timestamps[Preserve timestamps].
|
||||
+
|
||||
If there is more than one source, name them `Source1`, `Source2`.
|
||||
+
|
||||
If you add whole new files in addition to the pristine sources, list them as sources after the pristine sources. A copy of each of these sources is included in any source RPM (SRPM) you create, unless you specifically direct otherwise. For more information on special cases, for example, revision control, see https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/[Source URL].
|
||||
|
||||
`Patch0`::
|
||||
Enter the name of the first patch to apply to the source code. If you must patch the files after you extract them, edit the files and save their differences as a `.patch` file in your `~/rpmbuild/SOURCES` directory. Patches must make only one logical change each, so it's quite possible to have multiple patch files.
|
||||
|
||||
`BuildArch`::
|
||||
If you package files that are architecture-independent, for example shell scripts, data files, then add `BuildArch: noarch`. The architecture for the binary RPM is then `noarch`.
|
||||
|
||||
`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).
|
||||
|
||||
`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.
|
||||
+
|
||||
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 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.
|
||||
|
||||
`%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.
|
||||
+
|
||||
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.
|
||||
|
||||
`%prep`::
|
||||
Add script commands to "prepare" the program. For example, to extract the program, so that it is ready for building. Typically this is just `%autosetup`; a common variation is `%autosetup -n NAME` if the source file unpacks into `NAME`.
|
||||
|
||||
`%build`::
|
||||
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}`.
|
||||
|
||||
`%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.
|
||||
|
||||
`%clean`::
|
||||
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.
|
||||
|
||||
`%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.
|
||||
|
||||
`ExcludeArch`::
|
||||
If the package does not successfully compile, build or work on a particular architecture, list those architectures under this tag.
|
||||
|
||||
RPM also supports the creation of several packages called subpackages from a single `.spec` file, such as `name-libs` and `name-devel` packages.
|
||||
|
||||
Do *not* create a "relocatable" package; they do not add value in Fedora and make things more complicated.
|
||||
|
||||
|
||||
.Inserting comments
|
||||
|
||||
* 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 `#`.
|
||||
|
||||
* Avoid inline comments on the same line as script commands.
|
||||
|
|
@ -1,142 +0,0 @@
|
|||
[[creating_rpm_package]]
|
||||
= Creating an RPM package
|
||||
:experimental:
|
||||
include::{partialsdir}/attributes.adoc[]
|
||||
|
||||
.Overview
|
||||
|
||||
To create an RPM package, you must complete the following steps:
|
||||
|
||||
. Create a directory to store the package. Within the package directory, create a `.spec` file.
|
||||
. In the `.spec` file, add information about your software, instructions for unpacking it, building it, and installing it, as well as a list of files that are in the package.
|
||||
. Run the `fedpkg` command with the appropriate options to build your package.
|
||||
|
||||
. To create a directory, add a package, and within the package, create a simple program, enter the following commands:
|
||||
+
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
mkdir -p ~/packaging-work/howdy
|
||||
cd ~/packaging-work/howdy
|
||||
cat << EOF > howdy
|
||||
#!/bin/bash
|
||||
echo "Howdy, partner!"
|
||||
EOF
|
||||
chmod 644 howdy
|
||||
----
|
||||
+
|
||||
NOTE: The directory `packaging-work`, the package `howdy`, and program `howdy` names are for example purposes. Edit these names to suit your project. You can use any location you want but the directory name for the package should match the name of the package.
|
||||
+
|
||||
. To verify that everything built correctly, enter the following command:
|
||||
+
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ bash ./howdy
|
||||
----
|
||||
+
|
||||
. Create a new file `howdy.spec` and open `howdy.spec` in your text editor. Populate the `howdy.spec` file using the following example as a guide but change anything you require:
|
||||
+
|
||||
NOTE: Then you create the file, use spaces and do not use tabs to align the text.
|
||||
+
|
||||
[source]
|
||||
----
|
||||
Name: howdy
|
||||
Version: 1
|
||||
Release: 1%{?dist}
|
||||
Summary: Say hello, Texas style
|
||||
|
||||
License: Public Domain
|
||||
Source0: howdy
|
||||
|
||||
%description
|
||||
A simple program to greet the user, Texas style.
|
||||
|
||||
%install
|
||||
|
||||
%files
|
||||
|
||||
%changelog
|
||||
----
|
||||
+
|
||||
. To instruct the package how to install the program, add the following information to the `%install` section of the `.spec` file. Add the information to the line that follows `%install`:
|
||||
+
|
||||
[source]
|
||||
----
|
||||
mkdir -p %{buildroot}%{_bindir}
|
||||
install -p -m 755 %{SOURCE0} %{buildroot}%{_bindir}
|
||||
----
|
||||
+
|
||||
NOTE: In this example, we use the following three macros: `%\{buildroot}`, `%\{_bindir}`, and `%\{SOURCE0}`. This method ignores the origin of the files and directories and focuses on the destination of the files. Without `%\{buildroot}` the files might install directly onto your development machine. This is not recommended, especially if you run as root. For more information on macros and `.spec` file entries, see xref:con_rpm_spec_file_overview[].
|
||||
+
|
||||
. To tell RPM about the file, enter the following information to the `%files` section:
|
||||
+
|
||||
[source]
|
||||
----
|
||||
%{_bindir}/howdy
|
||||
----
|
||||
+
|
||||
NOTE: In general, the `%files` section is about files you have installed into the buildroot. You do not use the `%\{buildroot}` macro when listing files there.
|
||||
+
|
||||
. Save your edits and to run a local build, enter the following command:
|
||||
+
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ fedpkg --release f{MAJOROSVER} local
|
||||
----
|
||||
|
||||
This creates two RPMs; howdy-1-1.f{MAJOROSVER}src.rpm in same directory and <architecture>/howdy-1-1.f{MAJOROSVER}.rpm
|
||||
|
||||
.Adding no architecture dependencies
|
||||
|
||||
In this example, the package is a shell script, and there is no requirement for the package to build separately on every architecture that Fedora supports.
|
||||
|
||||
. To specify that this package is independent of architectures, open the file in your text editor and add the following information after the `Source0:` line:
|
||||
+
|
||||
[source]
|
||||
----
|
||||
BuildArch: noarch
|
||||
----
|
||||
+
|
||||
. Delete the existing `.rpm` files in this and sub directories and run another local build:
|
||||
+
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ fedpkg --release f{MAJOROSVER} local
|
||||
----
|
||||
|
||||
.Result
|
||||
|
||||
After you complete the procedure, ensure that you have the following two files:
|
||||
|
||||
. One source file that contains the latest source.
|
||||
. One binary file with the `.noarch.rpm`. inside `noarch` directory
|
||||
|
||||
.What to do next
|
||||
|
||||
Validate your RPM package with RPM lint, using the following command:
|
||||
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ fedpkg --release f{MAJOROSVER} lint
|
||||
----
|
||||
|
||||
At this stage, there are four or more errors because of the lack of `%prep`, `%build` sections, and `URL` tag.
|
||||
|
||||
To view the list of dependencies, enter the following command:
|
||||
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ rpm -qp --requires howdy-1-1.fc{MAJOROSVER}.noarch.rpm
|
||||
----
|
||||
|
||||
RPM adds some internal `rpmlib` dependencies, and one in `/bin/bash` which matches up with the first line of the howdy program.
|
||||
|
||||
To view a list of what the RPM provides, enter the following commnad:
|
||||
|
||||
[source,shell,subs="attributes"]
|
||||
----
|
||||
$ rpm -qp --provides howdy-1-1.fc{MAJOROSVER}.noarch.rpm
|
||||
----
|
||||
|
||||
This command is more important when your RPM package gains complexity and has dependencies.
|
||||
|
||||
For more information about building a more complete and complex RPM package, see https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package[How to create a GNU Hello RPM package].
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
[[preparing-your-system-to-create-rpm-packages]]
|
||||
= Preparing your system to create RPM packages
|
||||
|
||||
Before you create RPM packages on Fedora, you must install packaging tools and set up any accounts that you want to use.
|
||||
|
||||
For general information about preparing your environment, understanding source code, building and patching software, see the https://rpm-packaging-guide.github.io/#preparing-software-for-packaging[Preparing Software for Packaging] section in the RPM packaging guide.
|
||||
|
||||
This installs the utilities that you require to work with and build packages in the same manner as official Fedora packages, including the tool that the package reviewers use to check package quality.
|
||||
|
||||
To prepare your build environment to create RPM packages, complete the following steps:
|
||||
|
||||
NOTE: You must run the following two commands as the root user.
|
||||
|
||||
. Install the _fedora-packager_ and _fedora-review_ tools:
|
||||
+
|
||||
------------
|
||||
# sudo dnf install fedora-packager fedora-review
|
||||
------------
|
||||
+
|
||||
. Add yourself to the *mock* group:
|
||||
+
|
||||
-----------
|
||||
# sudo usermod -a -G mock yourusername
|
||||
-----------
|
||||
+
|
||||
. Log out and back in for this change to take effect.
|
||||
|
||||
. Run the `id` command to verify that the *mock* group appears in your group list:
|
||||
+
|
||||
----------------
|
||||
$ id
|
||||
----------------
|
||||
|
||||
NOTE: You can also create a separate user and use it for doing RPM development. Ensure that the user is part of the *mock* group and enters the `fedora-packager-setup` command.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
ifdef::context[:parent-context: {context}]
|
||||
:context: creating-rpm-packages
|
||||
[id='creating-rpm-packages']
|
||||
= Creating RPM packages
|
||||
|
||||
Learn the basics of RPM packaging.
|
||||
|
||||
include::{partialsdir}/con_rpm_packaging_overview.adoc[leveloffset=+1]
|
||||
|
||||
include::{partialsdir}/proc_rpm_preparing_your_system.adoc[leveloffset=+1]
|
||||
|
||||
include::{partialsdir}/proc_rpm_creating_an_rpm.adoc[leveloffset=+1]
|
||||
|
||||
include::{partialsdir}/con_rpm_spec_file_overview.adoc[leveloffset=+1]
|
||||
ifdef::parent-context[:context: {parent-context}]
|
||||
ifndef::parent-context[:!context:]
|
||||
|
|
@ -81,7 +81,7 @@ installs and packaged installs for (at least) the following reasons:
|
|||
|
||||
Strongly consider making your own package if you need a different
|
||||
version or a version of some package with changes. See:
|
||||
link:creating-rpm-packages[Creating RPM packages]
|
||||
xref:package-maintainers::Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello]
|
||||
|
||||
[[preferred-search-order-for-a-software]]
|
||||
Preferred search order for a software
|
||||
|
|
|
|||
|
|
@ -37,7 +37,10 @@ colors.py hellocopr.py __init__.py
|
|||
|
||||
. `tito` installed on your system. link:https://github.com/rpm-software-management/tito[Tito] is capable of a lot of advanced automation for package creation, most of which we won't need here. Check out its documentation to learn more.
|
||||
|
||||
. A specfile for our program. For more information on how to create one, refer to xref:creating-rpm-packages.adoc[Creating RPM packages] and xref:create-hello-world-rpm.adoc[How to Create a GNU Hello World RPM Package] or adapt this tutorial's link:https://pagure.io/copr-tito-quickdoc/blob/master/f/doc/hellocopr.spec.annotated[annotated example specfile].
|
||||
. A specfile for our program.
|
||||
For more information on how to create one,
|
||||
refer to xref:package-maintainers::Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello]
|
||||
or adapt this tutorial's link:https://pagure.io/copr-tito-quickdoc/blob/master/f/doc/hellocopr.spec.annotated[annotated example specfile].
|
||||
|
||||
TIP: You can follow along with this tutorial by cloning or forking the repository and checking out the `initial` tag. This will put the repository in the state just before the next step. The repo's commit history matches the steps followed in this tutorial.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue