Spec file variables

For example, they are set by fedpkg to override the default directories. The default build flags for binaries on fedora are also available via macros. The current definitions of these values can be found in the redhat-rpm-macros package, in the build flags documentation. Want to help? PyInstaller does not find this dependency.

You could add it to the bundle this way:. If you wish to store libiodbc. As with data files, if you have multiple binary files to add, to improve readability, create the list in a separate statement and pass the list by name. PyInstaller supports a more advanced and complex way of adding files to the bundle that may be useful for special cases. You can pass command-line options to the Python interpreter. The interpreter takes a number of command-line options but only the following are supported for a bundled app:.

W and an option to change warning behavior: W ignore or W once or W error. To pass one or more of these options, create a list of tuples, one for each option, and pass the list as an additional argument to the EXE call.

Each tuple has three elements:. The option as a string, for example v or W ignore. The unbuffered stdio mode the u option enables unbuffered binary layer of stdout and stderr streams on all supported Python versions. The unbuffered text layer requires Python 3. When you build a windowed Mac OS X app that is, running in Mac OS X, you specify the --onefile --windowed options , the spec file contains an additional statement to create the Mac OS X application bundle, or app folder:.

An Info. See the Apple bundle overview for a discussion of the contents of Info. PyInstaller creates a minimal Info. Its argument should be a Python dict with keys and values to be included in the Info. PyInstaller creates Info. By default all required system libraries are bundled. The function accepts an optional parameter that is a list of file wildcards exceptions, to not exclude library files that match those wildcards in the bundle.

For a splash screen to be displayed by the bootloader, the Splash target must be called at build time. For more information about the splash screen, see Splash Screen Experimental section. The Splash Target looks like this:. Splash bundles the required resources for the splash screen into a file, which will be included in the CArchive.

A Splash has two outputs, one is itself and one is stored in splash. Both need to be passed on to other build targets in order to enable the splash screen. To use the splash screen in a onefile application, please follow this example:. In order to use the splash screen in a onedir application, only a small change needs to be made.

The splash. This allows non-rectengular splash screen images. On Windows the transparent borders of the image are hard-cuted, meaning that fading transparent values are not supported. There is no common implementation for non-rectengular windows on Linux, so images with per- pixel transparency is not supported. The splash target can be configured in various ways. The constructor of the Splash target is as follows:. Only the PNG file format is supported. If a different file format is supplied and PIL Pillow is installed, the file will be converted automatically.

This TOC includes all extensionmodules and their dependencies. This is required to figure out, if the users program uses tkinter.

This TOC includes all data-file dependencies of the modules. See Specifying explicit assembly references below. These files are specified with a set of attributes that describe how they should be used within the project system.

See Specifying files to include in the package below. See Including assembly files and Including content files later in this topic for details. Specifies the minimum version of the NuGet client that can install this package, enforced by nuget. This is used whenever the package depends on specific features of the. For example, a package using the developmentDependency attribute should specify "2.

Similarly, a package using the contentFiles element see the next section should set minClientVersion to "3. Note also that because NuGet clients prior to 2. To use values from a project, specify the tokens described in the table below AssemblyInfo refers to the file in Properties such as AssemblyInfo. To use these tokens, run nuget pack with the project file rather than just the. Typically, when you have a project, you create the.

However, if a project lacks values for required. Furthermore, if you change project values, be sure to rebuild before creating the package; this can be done conveniently with the pack command's build switch. Tokens can also be used to resolve paths when you include assembly files and content files. The tokens have the same names as the MSBuild properties, making it possible to select files to be included depending on the current build configuration.

For example, if you use the following tokens in the. For example, the following lines indicate dependencies on PackageA version 1. The following lines indicate dependencies on the same packages, but specify to include the contentFiles and build folders of PackageA and everything but the native and compile folders of PackageB ". When creating a. Instead, use nuget pack myproject. Those dependencies are installed together when the target framework is compatible with the project's framework profile.

See Target frameworks for the exact framework identifiers. Explicit references are typically used for design-time only assemblies. For more information, see the page on selecting assemblies referenced by projects for more information.

Those references are added to a project when the target framework is compatible with the project's framework profile. Framework assemblies are those that are part of the.

Such assemblies, of course, are not included in a package directly. The following example shows a reference to System. Net for all target frameworks, and a reference to System. ServiceModel for. NET Framework 4. If you follow the conventions described in Creating a Package , you do not have to explicitly specify a list of files in the.

The nuget pack command automatically picks up the necessary files. When a package is installed into a project, NuGet automatically adds assembly references to the package's DLLs, excluding those that are named. For this reason, avoid using.

With NuGet 2. With NuGet 3. See Including content files below for details. Content files are immutable files that a package needs to include in a project. Note that rpmlint has very strict guidelines, and sometimes it is acceptable and necessary to skip some of its Errors and Warnings, as shown in the following examples.

For bello. It says that the URL listed in the Source0 directive is unreachable. This is expected, because the specified example. Presuming that we expect this URL to work in the future, we can ignore this warning. Assuming the link will be working in the future, we can ignore this warning.

The no-documentation and no-manual-page-for-binary warnings say that the RPM has no documentation or manual pages, because we did not provide any. There are many errors, because we intentionally wrote this SPEC file to be uncomplicated and to show what errors rpmlint can report. For the sake of this example, we ignore these errors, but for packages going in production you need a good reason for ignoring this error. Assuming that we expect the URL to become valid in the future, we can ignore this error.

Filesystem Hierarchy Standard. This directory is normally reserved for shared object files, which are binary files. This is an example of an rpmlint check for compliance with Filesystem Hierarchy Standard.

Normally, use RPM macros to ensure the correct placement of files. For the sake of this example, we can ignore this warning. Since this file contains the shebang , rpmlint expects the file to be executable. For the purpose of the example, leave this file without execute permissions and ignore this error.

The only warning for cello. Our RPMs are now ready and checked with rpmlint. This concludes the tutorial. This chapter covers topics that are beyond the scope of the introductory tutorial but are often useful in real-world RPM packaging.

Signing a package is a way to secure the package for an end user. Secure transport can be achieved with implementation of the HTTPS protocol, which can be done when the package is downloaded just before installing. However, the packages are often downloaded in advance and stored in local repositories before they are used. The packages are signed to make sure no third party can alter the content of a package. Adding a signature to an already existing package. Replacing the signature on an already existing package.

In most cases packages are built without a signature. The signature is added just before the release of the package. In order to add another signature to the package package, use the --addsign option. With two signatures, the package makes its way to a retailer. The retailer checks the signatures and, if they check out, adds their signature as well.

The package now makes its way to a company that wishes to deploy the package. After checking every signature on the package, they know that it is an authentic copy, unchanged since it was first created.

The two pgp strings in the output of the rpm --checksig command show that the package has been signed twice. RPM makes it possible to add the same signature multiple times. The --addsign option does not check for multiple identical signatures. To change the public key without having to rebuild each package, use the --resign option.

To sign a package at build-time, use the rpmbuild command with the --sign option. This requires entering the PGP passphrase. The "Generating signature" message appears in both the binary and source packaging sections. The number following the message indicates that the signature added was created using PGP.

When using the --sign option for rpmbuild , use only -bb or -ba options for package building. To verify the signature of a package, use the rpm command with --checksig option. For example:. When building multiple packages, use the following syntax to avoid entering the PGP passphrase multiple times.

For example when building the blather and bother packages, sign them by using the following:. Mock is a tool for building packages. It can build packages for different architectures and different Fedora or RHEL versions than the build host has. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot. Mock also offers a multi-package tool, mockchain , that can build chains of packages that depend on each other.

See —scm-enable in the documentation. From the upstream documentation. You can build for different distributions or releases just by specifying it on the command line. You simply specify the configuration you want to use minus the. For example, you could build our cello example for both RHEL 7 and Fedora 23 using the following commands without ever having to use different machines.

The build would succeed when you run rpmbuild because foo was needed to build and it was found on the system at build time. However, if you took the SRPM to another system that lacked foo it would fail, causing an unexpected side effect. Mock solves this by first parsing the contents of the SRPM and installing the BuildRequires into its chroot which means that if you were missing the BuildRequires entry, the build would fail because mock would not know to install it and it would therefore not be present in the buildroot.

As you can see, mock is a fairly verbose tool. For more information, please consult the Mock upstream documentation. Something to note is that storing binary files in a VCS is not favorable because it will drastically inflate the size of the source repository as these tools are engineered to handle differentials in files often optimized for text files and this is not something that binary files lend themselves to so normally each whole binary file is stored. As a side effect of this there are some clever utilities that are popular among upstream Open Source projects that work around this problem by either storing the SPEC file where the source code is in a VCS i.

In this section we will cover two different options for using a VCS system, git , for managing the contents that will ultimately be turned into a RPM package. One is called tito and the other is dist-git. Tito is an utility that assumes all the source code for the software that is going to be packaged is already in a git source control repository.

This is good for those practicing a DevOps workflow as it allows for the team writing the software to maintain their normal Branching Workflow. Tito will then allow for the software to be incrementally packaged, built in an automated fashion, and still provide a native installation experience for RPM based systems.

Tito operates based on git tags and will manage tags for you if you elect to allow it, but can optionally operate under whatever tagging scheme you prefer as this functionality is configurable. As we can see here, the spec file is at the root of the git repository and there is a rel-eng directory in the repository which is used by tito for general book keeping, configuration, and various advanced topics like custom tito modules.

We can see in the directory layout that there is a sub-directory entitled packages which will store a file per package that tito manages in the repository as you can have many RPMs in a single git repository and tito will handle that just fine. In this scenario however, we see only a single package listing and it should be noted that it matches the name of our spec file.

All of this is setup by the command tito init when the developers of dist-git first initialized their git repo to be managed by tito. We could then use the output as the installation point for some other component in the pipeline.

Below is a simple example of commands that could accomplish this and they could be adapted to other environments. Note that the final command would need to be run with either sudo or root permissions and that much of the output has been omitted for brevity as the dependency list is quite long.

This concludes our simple example of how to use tito but it has many amazing features for traditional Systems Administrators, RPM Packagers, and DevOps Practitioners alike. I would highly recommend consulting the upstream documentation found at the tito GitHub site for more information on how to quickly get started using it for your project as well as various advanced features it offers.

The build system is then configured to pull the items that are listed as SourceX entries in the spec files in from this look-aside-cache, while the spec and patches remain in a version control system. There is also a helper command line tool to assist in this. In an effort to not duplicate documentation, for more information on how to setup a system such as this please refer to the upstream dist-git docs.

You can define your own macros. Below is an excerpt from the RPM Official Documentation , which provides a comprehensive reference on macros capabilities. A parameterized macro contains an opts field. The shell output is set with set -x enabled. DhddsG use the --debug option, since rpmbuild deletes temporary files after successful build.

This displays the setup of environment variables, for example:. Only tar -xof is executed instead of tar -xvvof.

This option has to be used as first. For example, if the package name is cello , but the source code is archived in hello The -c option can be used if the source code tarball does not contain any subdirectories and after unpacking, files from an archive fill the current directory.

The -c option creates the directory and steps into the archive expansion. An illustrative example:. Essentially, -D option means that following lines are not used:. The -T option disables expansion of the source code tarball by removing the following line from the script:. Option -b which stands for before expands specific sources before entering the working directory.

Option -a which stands for after expands those sources after entering. Their arguments are source numbers from the spec file preamble. In this case use -a 1 , as we want to expand Source1 after entering the working directory:. But if the examples were in the separate cello This identifies the file listed as documentation and it will be installed and labeled as such by RPM. This is often used not only for documentation about the software being packaged but also code examples and various items that should accompany documentation.

In the event code examples are included, care should be taken to remove executable mode from the file. Identifies that the path is a directory that should be owned by this RPM. This is important so that the RPM file manifest accurately knows what directories to clean up on uninstall.

Specifies that the following file is a configuration file and therefore should not be overwritten or replaced on a package install or update if the file has been modified from the original installation checksum. In the event that there is a change, the file will be created with.

Your system has many built-in RPM Macros and the fastest way to view them all is to simply run the rpm --showrc command. Note that this will contain a lot of output so it is often used in combination with a pipe to grep. Different distributions will supply different sets of recommended RPM Macros based on the language implementation of the software being packaged or the specific guidelines of the distribution in question.

These are often provided as RPM Packages themselves and can be installed with the distribution package manager, such as yum or dnf. One primary example of this is the Fedora Packaging Guidelines section pertaining specifically to Application Specific Guidelines which at the time of this writing has over 60 different sets of guidelines along with associated RPM Macro sets for subject matter specific RPM Packaging.

One example of this kind of RPMs would be for Python version 2. The above output displays the raw RPM Macro definitions, but we are likely more interested in what these will evaluate to which we can do with rpm --eval in order to determine what they do as well as how they may be helpful to us when packaging RPMs. Any changes you make will affect every build on your machine. You can create this directory, including all subdirectories using the rpmdev-setuptree utility.

By default, it is set to -jX , where X is a number of cores. If you alter the number of cores, you can speed up or slow down a build of packages.

In this section we will cover the most common of these such as Epoch, Scriptlets, and Triggers. First on the list is Epoch , epoch is a way to define weighted dependencies based on version numbers. This was not covered in the SPEC File section of this guide because it is almost always a bad idea to introduce an Epoch value as it will skew what you would normally otherwise expect RPM to do when comparing versions of packages.

For example if a package foobar with Epoch: 1 and Version: 1. This approach is generally only used when absolutely necessary as a last resort to resolve an upgrade ordering issue which can come up as a side effect of upstream software changing versioning number schemes or versions incorporating alphabetical characters that can not always be compared reliably based on encoding.

In RPM Packages, there are a series of directives that can be used to inflict necessary or desired change on a system during install time of the RPM. These are called scriptlets. At install time we will need to notify systemd that there is a new unit so that the system administrator can run a command similar to systemctl start foo.

Scriptlet that is executed just before the package is installed on the target system. Scriptlet that is executed just after the package is installed on the target system. Scriptlet that is executed just before the package is uninstalled from the target system. Scriptlet that is executed just after the package is uninstalled from the target system.

It is also common for RPM Macros to exist for this function. In our previous example we discussed systemd needing to be notified about a new unit file , this is easily handled by the systemd scriptlet macros as we can see from the below example output. More information on this can be found in the Fedora systemd Packaging Guidelines. Another item that provides even more fine grained control over the RPM Transaction as a whole is what is known as triggers.

These are effectively the same thing as a scriptlet but are executed in a very specific order of operations during the RPM install or upgrade transaction allowing for a more fine grained control over the entire process. An illustrative example is a script, which prints out a message after the installation of pello.