Cetos systemname archive#
This description can span multiple lines and can be broken into paragraphs.Ĭommand or series of commands to prepare the software to be built, for example, unpacking the archive in Source0.
Cetos systemname full#
This table lists the items used in the Body section of the RPM SPEC file:Ī full description of the software packaged in the RPM. If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here. There can be multiple entries of Requires, each on its own line in the SPEC file. There can be multiple entries of BuildRequires, each on its own line in the SPEC file.Ī comma- or whitespace-separated list of packages required by the software to run once installed. If not set, the package automatically inherits the Architecture of the machine on which it is built, for example x86_64.Ī comma- or whitespace-separated list of packages required for building the program written in a compiled language. If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to BuildArch: noarch. If needed, more PatchX directives can be added, incrementing the number each time, for example: Patch1, Patch2, Patch3, and so on.
Cetos systemname Patch#
The name of the first patch to apply to the source code if necessary. If needed, more SourceX directives can be added, incrementing the number each time, for example: Source1, Source2, Source3, and so on. This should point to an accessible and reliable storage of the archive, for example, the upstream page and not the packager’s local storage. Path or URL to the compressed archive of the upstream source code (unpatched, patches are handled elsewhere). Most often this is the upstream project website for the software being packaged. The full URL for more information about the program. The license of the software being packaged.įor packages distributed in community distributions such as Fedora this must be an open source license abiding by the specific distribution’s licensing guidelines. Reset to 1 when a new Version of the software is built.Ī brief, one-line summary of the package. Normally, set the initial value to 1%, and increment it with each new release of the package. The number of times this version of the software was released. The upstream version number of the software. The base name of the package, which should match the SPEC file name. This table lists the items used in the Preamble section of the RPM SPEC file: Using a GPG signing key, you can digitally sign your package so that users areĪble to verify the authenticity of the package. You can add your package to a Yum repository that enables clients to easily findĪnd deploy your software. This design eases the maintenance of the packages as new versions of your Sources along with any patches that were used, plus complete build instructions. In source packages, you have the pristine RPM allows you to take pristine software sources and package them into sourceĪnd binary packages for your users.
Package pristine software sources into source and binary packages Version, release, size, project URL, installation instructions, and so on. Use metadata to describe packages, their installation instructions, and so onĮach RPM package includes metadata that describes the package’s components, Use a database of installed packages to query and verify packagesīecause RPM maintains a database of installed packages and their files, usersĬan easily query and verify packages on their system.
Cetos systemname upgrade#
To install, reinstall, remove, upgrade and verify your RPM packages.
Users can use standard package management tools (for example Yum or PackageKit)
Install, reinstall, remove, upgrade and verify packages
0 kommentar(er)
