How To Install Rpm In Suse

A package is a mode of distributing software on Linux systems. A single application is distributed every bit one or more than packages. Normally the main packet contains the program, and in addition some optional or secondary packages.

On some platforms, applications are self-contained into a directory. This ways installing an application is simply adding a directory, and uninstalling the application is simply removing this directory.

Linux systems tend to share as much of their components as possible. Partly this is the instance because of some advantages of this philosophy. But mainly it happens because of the fact that in the Linux ecosystem, the whole universe is built by the same entity, except for a few 3rd party applications. This makes it easy to assume that a library is available for all applications to consume.

In a MacOS system, simply the core comes from a single vendor, and all applications are provided by 3rd party suppliers. Information technology is therefore harder to make assumptions, and they tend to ship their ain version of whatever depending component, with the exception of everything being documented equally the "platform".

As an instance, we start with a well-known UNIX tool: rsync.

A package is an archive file:

rsync-3.ane.2-1.5.x86_64.rpm

This archive file contains all files related to the application:

$ rpm -qpl rsync-three.1.2-1.5.x86_64.rpm  /etc/logrotate.d/rsync /etc/rsyncd.conf /etc/rsyncd.secrets /etc/sysconfig/SuSEfirewall2.d/services/rsync-server /etc/xinetd.d/rsync /usr/bin/rsync /usr/bin/rsyncstats /usr/lib/systemd/system/rsyncd.service /usr/sbin/rcrsyncd /usr/sbin/rsyncd /usr/share/doc/packages/rsync /usr/share/doc/packages/rsync/COPYING /usr/share/doc/packages/rsync/NEWS /usr/share/doc/packages/rsync/README /usr/share/doctor/packages/rsync/tech_report.tex /usr/share/man/man1/rsync.one.gz /usr/share/man/man5/rsyncd.conf.v.gz

Additionally, it contains some extra metadata. This metadata should include merely it is not express to:

Name
Summary
Clarification
License
etc.

As an example, the metadata for rsync expect as follows:

$ rpm -qpi rsync-3.1.2-1.5.x86_64.rpm  Proper noun        : rsync Version     : three.1.2 Release     : 1.5 Architecture: x86_64 Install Appointment: Wed 26 Oct 2022 01:31:12 PM CEST Group       : Productivity/Networking/Other Size        : 636561 License     : GPL-iii.0+ Signature   : RSA/SHA256, Mon 17 Oct 2022 02:32:twoscore AM CEST, Key ID b88b2fd43dbdc284 Source RPM  : rsync-iii.1.2-1.5.src.rpm Build Date  : Monday 17 Oct 2022 02:32:26 AM CEST Build Host  : lamb18 Relocations : (not relocatable) Packager    : http://bugs.opensuse.org Vendor      : openSUSE URL         : http://rsync.samba.org/ Summary     : Versatile tool for fast incremental file transfer Description : Rsync is a fast and extraordinarily versatile file  copying  tool. It can copy locally, to/from another host over whatsoever remote shell, or to/from a remote rsync daemon. It offers a big number of options that control every aspect of its behavior and let very flexible specification of the prepare of files to be copied. It is famous for its delta-transfer algorithm, which reduces the corporeality of data sent over the network past sending only the differences betwixt the source files and the existing files in the destination. Rsync is widely used for backups and mirroring and as an improved copy command for everyday utilize. Distribution: openSUSE Tumbleweed

To get a list of boosted packages which the respective parcel requires to exist installed to work, utilize the control Requires as shown below:

$ rpm -qp --requires rsync-3.ane.2-ane.5.x86_64.rpm /bin/sh /usr/bin/perl config(rsync) = 3.one.two-i.five coreutils diffutils fillup grep libacl.and so.ane()(64bit) libacl.so.i(ACL_1.0)(64bit) libc.so.6()(64bit) libc.then.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.and then.6(GLIBC_2.15)(64bit) libc.so.six(GLIBC_2.2.5)(64bit) libc.so.half-dozen(GLIBC_2.3)(64bit) libc.then.half dozen(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.and so.6(GLIBC_2.6)(64bit) libc.so.6(GLIBC_2.7)(64bit) libc.so.half-dozen(GLIBC_2.8)(64bit) libpopt.so.0()(64bit) libpopt.so.0(LIBPOPT_0)(64bit) libslp.so.i()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-ane rpmlib(PayloadFilesHavePrefix) <= 4.0-ane rpmlib(PayloadIsLzma) <= four.4.vi-1 sed systemd

As an example, a package may need a library, or an executable that is chosen during runtime.

To get a list of information the respective bundle provides for other packages to piece of work, apply the command Provides as shown below:

$ rpm -qp --provides rsync-three.1.ii-ane.5.x86_64.rpm config(rsync) = 3.one.2-1.v rsync = 3.1.2-i.5 rsync(x86-64) = 3.1.two-1.5

When a package is installed, the content (or list of files) is placed on the system at the location of each file path relative to the root (/) directory.

Additionally, the metadata of the package (and the fact that it is installed) is recorded in a system-wide database located in /var/lib/rpm. This is managed by the rpm tool, the utility that manages packages at the everyman level.

Packages can be installed with the rpm tools:

$ rpm -U rsync-3.1.two-i.5.x86_64.rpm

When you practise this, you can perform the aforementioned queries without specifying the -p option and using what is called the NVRA (name-version-release-architecture, rsync-3.1.2-ane.v.x86_64) or a subset of it, for example, just the proper noun (rsync).

$ rpm -q --provides rsync

The rpm tool will not assist you if the dependencies of the package are not met at installation time. Information technology volition and so refuse to install the parcel to avoid having the system in an inconsistent state.

Features like automatically finding the required packages and retrieving them, are implemented in higher-level tools like zypper.

The section Section i.ane, "Beefcake of a Package" explains that a package contains a list of Requires and Provides. Those are not package names, simply arbitrary symbols. A parcel tin can require or provide any string of text.

The main dominion is that each package provides its own name. This ways the rsync parcel Provides: rsync.

Y'all have also learned that rsync requires /bin/sh. While this looks similar a file proper noun, in our context it is an capricious symbol and the meaning is given past the whole distribution. The reason why information technology does not require a package named sh instead is that it provides a layer of indirection that makes the system cohesive.

/bin/sh is a adequacy provided by the bash packet. This allows rsync to depend on any trounce implementation as long as information technology provides that symbol.

The distribution build arrangement will scan all executables a bundle installs in a organisation and inject automatically those Provides. The packager does not need to take care of them.

The same is done with libraries. As an example, rsync does non depend on the glibc bundle. When glibc was built, the build system scanned the content, found /lib64/libc.so.6 and injected a Provides: libc.so.6()(64bit) into the glibc metadata. In the case of shared libraries information technology is not so important where they are located, considering the linker configuration takes intendance of that. When the rsync bundle was built (glibc needed to be installed at that bespeak to build it), the build system scanned the executable /usr/lib/rsync and realized information technology was linked against libc.so.6:

$ ldd /usr/bin/rsync         linux-vdso.then.ane (0x00007ffccb34a000)         libacl.so.1 => /lib64/libacl.so.one (0x00007fc406028000)         libpopt.and so.0 => /usr/lib64/libpopt.then.0 (0x00007fc405e1b000)         libslp.and then.i => /usr/lib64/libslp.so.one (0x00007fc405c02000)         libc.so.six => /lib64/libc.and then.half-dozen (0x00007fc405863000)         libattr.so.ane => /lib64/libattr.so.1 (0x00007fc40565e000)         libcrypto.and so.1.0.0 => /lib64/libcrypto.so.i.0.0 (0x00007fc4051c4000)         libpthread.and so.0 => /lib64/libpthread.so.0 (0x00007fc404fa7000)         /lib64/ld-linux-x86-64.so.2 (0x00005653cd048000)         libdl.so.2 => /lib64/libdl.then.2 (0x00007fc404da3000)         libz.so.i => /lib64/libz.and so.1 (0x00007fc404b8d000)

Therefore, it injected Requires: libc.then.six()(64bit) to the rsync packet.

Now compare information technology to other packaging systems. The package musicplayer requires libsound. /usr/bin/musicplayer links to /usr/lib64/libsound.and so.v. At a later point in fourth dimension, musicplayer is rebuilt confronting a newer libsound, which is not published. The user installs musicplayer without any upshot because it just Requires: libsound (every bit in the package name). However, when the user tries to run it, he or she gets the following message:

$ musicplayer mistake while loading shared libraries: libsound.so.7: cannot open up shared object file: No such file or directory

The layer of indirection of automatically injected dependencies prevents this manual work from keeping dependencies in synchronization. Packages just provide what they really carry (considering provides are injected by advanced scanners). Packages only require what they really need (because requires are injected past scanning executables, scripts for shebangs, etc.).

This allows rpm based distributions to use these conventions highly cohesive. It makes upgrades less problematic and the danger of breaking your system near non-real. At the same time, the conventions and indirections between Provides and Requires allow for packages to depend on more than abstract capabilities, instead of specific package names (which sometimes get renamed, separate, obsoleted, etc). For instance, you can be certain the vim bundle provides half dozen.

In that location are also other dependencies with more advances purposes: Conflicts, Obsoletes, etc. Their names permit yous easily understand what purposes they have.

Not everything is every bit strict every bit you might recollect. Sometimes a package works better if another bundle is present. Sometimes a parcel enhances the functionality of another packet, notwithstanding in neither case they are required. For this purpose, packages tin can have the following dependencies:

Recommends: a soft version of requires. If the recommended packages are non installed, the package volition be installed anyway. Higher level tools however may pull automatically recommended packages based on user settings.
The reverse of this dependency is Supplements. For case a package spellchecker could Supplements an office-suite package.
Suggests and Enhances:the forward and backward version of Recommends and Supplements in a weaker version.

For daily organisation administration and maintenance, the rpm tool does not suffice. You will quickly autumn into what is commonly called the "dependency hell". This means you download packages manually to speedily satisfy a dependency, but and so you realize the new packet implicates another dependency.

This problem is taken intendance of by a tool that implements a solver. The solver considers:

The list of installed packages (and therefore all its dependencies)
The list of bachelor packages
The user request ("install packet foo", "upgrade system")

The solver performs an performance that finds the all-time solution to a trouble that has many solutions. Therefore "best" is divers by policies, user settings, the distribution itself, etc.

On SUSE systems, the solver is implemented by the libsolv /> project (run into more at https://github.com/openSUSE/libsolv. This engine implements both a satisfiability algorithm and an efficient mode to stand for the problem in memory. Originally it was developed by Michael Schroeder at SUSE, but today information technology powers besides other distribution package managers, such as Fedora'due south dnf.

The rest of the package managing director includes:

Treatment of packet repositories
Checking the integrity of packages
Fetching remote packages
Reading and honoring user/system policies

In SUSE systems, this functionality is implemented by the ZYpp (see https://en.opensuse.org/Portal:Libzypp)library, which too includes a command-line tool called zypper. While tools similar YaST (meet https://yast.github.io/) also interact with ZYpp , on the panel you volition likely interact with zypper. The command

$ zypper install rsync-3.1.two-one.5.x86_64.rpm

will, unlike rpm, check what else your organization is missing, retrieve it, and so install all the required packages in the right guild. It will also warn y'all if another packet conflicts with what you lot are installing, or if the performance has more than one solution, and ask you for your conclusion what to do.

Simply from where does the system "call back other packages"?

zypper can install a package straight from an rpm file. If in that location is the need for installing dependencies or retrieving packages – for example when you upgrade a system - you lot will demand a "library" of packages. This is what is chosen a repository. A repository is:

A collection of packages
A set of metadata files

The metadata is nothing more than than the data present in the rpm file (Name, Description, Dependencies). The metadata allows the bundle manager to operate with the repository without having stored all rpm files locally. Every operation that is candy uses the given information of the package, and then the rpm files are retrieved on demand at installation time.

$ zypper lr  # | Alias          | Name           | Enabled | GPG Check | Refresh --+----------------+----------------+---------+-----------+-------- i | non-oss        | NON-OSS        | Yes     | ( p) Yes  | Yes 2 | oss            | OSS            | Yes     | ( p) Yes  | Yes 3 | oss-update     | OSS Update     | Yep     | ( p) Yep  | Yes iv | update-not-oss | Update Non-Oss | Yes     | ( p) Aye  | Yeah

A system commonly will have the following repositories:

The base repository, which contains all the distribution packages
Additional modules, improver products or extensions
An update repository for each base product or extension

Running listing repositories with -u will display the URI of the repository:

zypper lr -u             http://download.opensuse.org/update/bound/42.ii/oss/.

If you visit the URI, you will see:

a x86_64 directory containing all architecture-dependent packages (this means ones that comprise executables, shared libraries, etc)
a noarch directory containing compages-independent packages (this means ones containing information or scripts)
a repodata directory, containing the metadata for all packages

The metadata for this type of repositories consists in a repodata/repomd.xml file index, which is signed (repomd.xml.asc) using a fundamental already present in the original system. repodata/repomd.xml refers to other metadata file with their checksums. The most important file is primary.xml which contains all packet dependencies.

If you have a directory with rpm packages, you lot can create the metadata for them using the createrepo tool. Afterward that you tin can serve that repository via HTTP.

If yous have a directory with rpms you lot desire to utilize as repository, y'all don't need to add metadata. ZYpp allows to have a plain local directory as a repository, and will read the metadata direct from the rpm files into its cache.

You can refresh a repository with the command

$ zypper ref

While the base repository of the distribution is normally immutable, repositories like the i containing updates often get new content. The purpose of refreshing a repository is to get the upwardly-to-date version of the metadata locally, so that all operations (solving, retrieval) lucifer the current content of the repository.

If a repository is out of date, it means the local metadata represents a previous version of the repository content. You lot could try to solve this and fetch packages, just those packages may not exists on the repository anymore, and you will get an error at retrieval time.

The list of repositories of the system is kept in /etc/zypp/repos.d. zypper provides most of repository operations in a safer way than trying to update these files manually.

During refresh, metadata is cached locally at /var/enshroud/zypp/raw and converted to an efficient format for solving operations in /var/enshroud/zypp/solv.

Services are a higher-level version of repositories. It is some other index that lists repositories. When the system is subscribed to a service, refreshing the service volition result in a new listing of repositories, and the package managing director volition add new ones or remove obsolete ones.

Services are used for example on SUSE Linux Enterprise with the SUSE Customer Center (SCC). A customer is subscribed to a service provided by SCC using proper credentials. The client, based on his or her entitlements, can "activate" a new product. SUSE Customer Center knows almost those activations, and on service refresh, it volition provide a new list of repositories that includes the new activated product.

Services can exist installed remote (similar SCC), or locally, via a plug-in, on the system. The package manager asks the plug-in for a list of repositories. Information technology is up to the plug-in to build this list. This is normally used for integration with other systems. For example, the connectivity betwixt zypper and Spacewalk corresponding SUSE Managing director (come across https://www.suse.com/products/suse-director/ was originally implemented using a local plug-in.

If you are using SUSE Linux Enterprise, your repositories will appear later on the SUSEConnect tool registers your production against the SUSE Customer Center at https://scc.suse.com/login.

If you lot are using openSUSE, the default installation will set the base and update the repositories. Additionally, there is a lot of content published by the customs on the build service projects or via projects like packmanpackman (see http://packman.links2linux.org/.

SUSE Linux Enterprise users can take reward of the community content via the Bundle Hub at https://packagehub.suse.com/.

Yous can utilize zypper lu to list updates, and zypper up to install them.

You can lock packages to avert them beingness removed or pulled-in using zypper addlock or zypper removelock. Y'all tin can also list active locks with zypper locks.

The distribution upgrade operation dup is used to practice destructive upgrades. This means packages may be suggested for removal as dependencies similar Obsoletes are taken into business relationship. It is usually used to upgrade to major releases or to update rolling distributions like Tumbleweed (see https://en.opensuse.org/Portal:Tumbleweed. This command needs to be used with care.

2.iii Other Solvable Types (Products, Patterns, Arrangement) #Edit source

The packet manager solver loads all available and installed packages and cares for solving the dependencies. However, there are other entities similar to packages that also take dependencies.

Patterns are used to install a collection of software in a comfy way. For example you tin can install a working Laptop-oriented organization with the command:

$ zypper install -t design laptop

But where exercise patterns come up from? They practice not exists on their own. The package managers creates them dynamically from packages named patterns-XXXXXX which take a special set of dependencies. Installing a pattern would actually install the package representing that pattern. The other way around is true, if you install the parcel representing the design, it will make the system wait similar the pattern is installed.

The command:

$ zypper info --provides patterns-openSUSE-laptop

reveals some detail behind patterns (equivalent to rpm -q --provides patterns-openSUSE-laptop).

Similar to patterns, products tin be queried with:

$ zypper search -t product

"Production" comes from a package called XXXXXX-release which has some special dependencies (rpm -q --provides openSUSE-release). The release packet/product installs some information in /etc/products.d that is used by other tools become information almost the base and add together-on products installed.

Patches are used for updates and described past the updateinfo.xml section of the metadata. They represent an entity that conflicts with older versions of one or more packages. Installing a patch does not install packages, only generates a conflict in the solver that ends with the affected version of packages beingness upgraded.

Patches also carry additional property, similar the CVE (see https://cve.mitre.org/identifiers of the issues they gear up or links to bug tracker incidents.

During solving, there is ane entity providing dependencies that is used to match locale and hardware information. If you accept a Wi-Fi carte du jour, the package manager will dynamically read /sys/devices and brand this entity accept provides like:

Provides :modalias(pci:v0000104Cd0000840[01]sv*sd*bc*sc*i*)

A package providing a Wi-Fi driver for some cards (for instance, wlan-kmp-default), could have the following dependencies:

Supplements: modalias(kernel-default:pci:v0000104Cd0000840[01]sv*sd*bc*sc*i*) Supplements: modalias(kernel-default:pci:v0000104Cd00009066sv*sd*bc*sc*i*) Supplements: modalias(kernel-default:pci:v000010B7d00006000sv*sd*bc*sc*i*)

This results in the fact that, at solving time, if the hardware is present, the driver will be selected automatically.

Something similar is done with translation packages and the electric current configured system locale.

Important: All Data Comes from the Installed Packages

Be aware that all those types mentioned (Patterns, Products, System) are only present at solving time. Actually your system consists only of packages, and all information comes from the installed packages. Every operation on patches, patterns and products result in a package performance. The purpose behind is to make the package manager compatible with the lower level rpm tool.

When packages are created they provide a so called .spec file. A spec file defines the attributes of the package, explicit dependencies (others are injected every bit already mentioned), and how the content of the parcel is created. A very simple spec file would be:

Proper name:           mypackage Version:        1.0 Release:        0 License:        MIT Summary:        Dummy package BuildRoot:      %{_tmppath}/%{name}-%{version}-build  %description Dummy text  %install mkdir -p %{buildroot}%{_datadir}/%{proper name} bear on %{buildroot}%{_datadir}/%{proper noun}/CONTENT  %files %defattr(-,root,root) %{_datadir}/%{name}/CONTENT  %changelog

This spec file creates a directory /usr/share/mypackage and puts a dummy CONTENT file in it.

spec files are heavily defined by macros that make sure that paths and values are specified by the distribution. Those macros are shipped by the base distribution and are located in /usr/lib/rpm and /etc/rpm. Other packages may contribute more macros. For example the macros defined in /usr/lib/rpm/golang-macros.rb are provided past the golang-packaging parcel and are useful to create packages that use the Go language.

When edifice spec files, you should exist familiar with macros similar %{_prefix} , %{_datadir} , %{_mandir} , %{_libdir} , %{_bindir} , etc... You can evaluate a macro every bit follows:

$ rpm --eval "%{_libdir}" /usr/lib64

Sometimes yous will build multiple components from a single source that are independent of each other.

The sources for a package Part Suite may issue in:

A Word Processor
A Spreadsheet
Common libraries
Evolution files

For this, you can declare subpackages, independent description and attributes sections for each component. The build department is mutual to all subpackages, and so again in the %files department, you lot volition declare which files go to each subpackage. In this case, the subpackages could exist:

office-wordprocessor
office-spreadsheet
liboffice
office-devel

You can build a bundle with the rpmbuild tool. It requires the spec file to be in a specific location. You lot can tweak the standard configuration to search spec files in the electric current directory:

$ cat ~/.rpmmacros %topdir /infinite/packages %_builddir %{topdir}/build %_rpmdir %{topdir}/rpms %_sourcedir %(echo $PWD) %_specdir %(echo $PWD) %_srcrpmdir %{topdir}/rpms

You can configure it so that congenital packages are saved in /space/packages. Brand the tweaks according to your own preferences.

When this is set up, enter the post-obit command:

$ rpmbuild -bb mypackage.spec Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.lVzwnj + umask 022 + cd /space/packages/build + mkdir -p /dwelling/duncan/rpmbuild/BUILDROOT/mypackage-1.0-0.x86_64/usr/share/mypackage + bear upon /abode/duncan/rpmbuild/BUILDROOT/mypackage-1.0-0.x86_64/usr/share/mypackage/CONTENT + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-suse Processing files: mypackage-1.0-0.x86_64 Provides: mypackage = 1.0-0 mypackage(x86-64) = 1.0-0 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-i rpmlib(PayloadFilesHavePrefix) <= 4.0-ane Checking for unpackaged file(south): /usr/lib/rpm/cheque-files /dwelling/duncan/rpmbuild/BUILDROOT/mypackage-ane.0-0.x86_64 Wrote: /space/packages/rpms/x86_64/mypackage-one.0-0.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.0xLGri + umask 022 + cd /space/packages/build + /usr/bin/rm -rf /home/duncan/rpmbuild/BUILDROOT/mypackage-one.0-0.x86_64 + rm -rf filelists

Now you can verify the content of the package:

% rpm -qpl /space/packages/rpms/x86_64/mypackage-1.0-0.x86_64.rpm /usr/share/mypackage/CONTENT

Everything that you put into the %{buildroot} did end up as content of the package.

The term "building a package" can accept ii meanings. I is assembling the bundle from existing content. You could build your awarding in Jenkins, take the built artifacts and use the spec file to package information technology.

However, where rpm excels is that you can build the awarding in the spec file itself, and use the distribution and dependencies to gear up upward the build surroundings.

A mutual use example to illustrate this is the typical Linux awarding built with configure && make && make install. In the side by side example you lot build a parcel for gqlplus (see http://gqlplus.sourceforge.cyberspace/, an alternative client for Oracle databases.

Provided that you accept readline and ncurses development headers, you tin can build this application by unpacking the TAR archive and performing the commands mentioned above. Some programs require an extra stride with autoconf to generate the configure script. This is specific to building software and has zero to do with packaging.

When you do ./configure you need to pass the correct --prefix. Macros tin assist here. You could utilize the command configure --prefix=%{_prefix}. All the same, there is a better macro called %configure which takes care and sets well-nigh of the configuration options (You can also try expanding it with repeat $(rpm --eval '%configure')).

The packet cannot build if some libraries are not nowadays. A C compiler is there, but the bones build tools (brand) are not available. That is what BuildRequires are for. They define what packages are needed for building - but not necessarily at runtime.

On the other paw, the original oracle-instantclient-sqlplus bundle is required at runtime, simply you practise non demand it to build your package.

Name:           gqlplus Version:            one.15 Release:            0 License:            GPL-2.0 Summary:            A drop-in replacement for sqlplus, an Oracle SQL client Url:                http://gqlplus.sourceforge.internet/ Grouping:              Productivity/Databases/Clients Source0:            %{proper noun}-%{version}.tar.bz2 BuildRequires:  readline-devel BuildRequires:  ncurses-devel BuildRequires:  gcc make autoconf automake BuildRoot:      %{_tmppath}/%{name}-%{version}-build Requires:       oracle-instantclient-sqlplus %clarification GQLPlus is a drib-in replacement for sqlplus, an Oracle SQL customer, for Unix and Unix-like platforms. The difference between GQLPlus and sqlplus is command-line editing and history, plus table-name and cavalcade-proper noun completion.  %prep %setup -q  %build aclocal && autoconf automake --add-missing %configure make %{?_smp_mflags}  %install %makeinstall  %files %defattr(-,root,root) %doc ChangeLog README LICENSE %{_bindir}/gqlplus  %changelog

The Source0 section specifies a source that you tin can refer later using the %SOURCE0 or %{S:0} macros. You can accept more one source ( Source1 , etc).

The prep section uses the %setup macro (run into http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html#S2-RPM-Within-SETUP-MACROto unpack the sources. You could as well operate directly on the source files if you lot demand to do something unconventional.

Equally nosotros need make install to install the files inside %{buildroot} , we should call brand install DESTDIR=%{buildroot}, but %makeinstall is a macro for that.

The files section list the files rpmbuild should expect to discover inside the %{buildroot} macro that will be the content of the package.

Notation: Not Needed at Runtime

You practise not demand to add a runtime Requires to the readline and ncurses libraries. Because the executable is linked confronting the ones installed by the -devel packages, information technology volition be scanned and the correct Requires will be injected:

$ rpm -qp --requires gqlplus-ane.15-0.x86_64.rpm libc.and then.vi()(64bit) ... libncurses.so.6()(64bit) libreadline.and so.7()(64bit) oracle-instantclient-sqlplus ...

These symbols are provided past the right bundle, thus the solver will match them:

rpm -q --whatprovides 'libncurses.so.vi()(64bit)' libncurses6-6.0-19.1.x86_64

For more data on how to build packages for various types of software, visit the openSUSE Packaging Guidelines at https://en.opensuse.org/openSUSE:Packaging_guidelines.

Building this style means the build surround is your system. If a package is bachelor in BuildRequires , y'all will accept to install it on your organisation first.

If the software you are building links confronting some library but if it is bachelor, even if yous practise not mention it in your BuildRequires , if that library is present in your system, it will taint the build and make the command configure find it.

The following section outlines what to do if you want to build against only the packages that are in the build requirements.

The Open up Build Service at http://openbuildservice.org/ allows to build packages for multiple distributions and architectures. Visit the Materials section of the Web site (see http://openbuildservice.org/help/) for a deeper introduction. For the parcel you are building, y'all can become an business relationship at the openSUSE Build Service instance. Go to your "Home Project", and click "Create New Bundle". Upload the spec file and sources.

Later on that you need to configure some target distributions for your dwelling project. That tin be one base distribution, or another project. This shows the power by allowing building based on layers that tin override things from previous layers.

Add together the well-nigh popular (open)SUSE distributions (latest Leap and Tumbleweed) and your packet will be built automatically. A repository volition be published automatically and made available for public consumption.

Every time the sources change, the package will be rebuilt. If you lot have more packages in the same project, those will be rebuilt in the right guild, and re-published.

Open Build Service Overview of Packages

Figure 1: Open up Build Service Overview of Packages #

The Open Build Service cannot only build packages, but besides images from those packages. All SUSE products and the openSUSE distributions are built using the Open Build Service. Contributors submit new sources, and the Open Build Service takes care of assembling everything (and openQA later on ensures that everything works).

With the osc tool you can checkout packages from the Open Build Service, make changes to them and resubmit them.

$ osc co home:dmacvicar gqlplus A    dwelling house:dmacvicar A    home:dmacvicar/gqlplus A    home:dmacvicar/gqlplus/gqlplus-1.15.tar.bz2 A    home:dmacvicar/gqlplus/gqlplus.changes A    home:dmacvicar/gqlplus/gqlplus.spec At revision 4.

The most interesting characteristic is the ability to build packages or images locally. osc allows you to build in an isolated environment (either a chroot jail [see https://en.wikipedia.org/wiki/Chroot] or a virtual car) by setting up that environment automatically using the BuildRequires of the spec file. It also allows you to build against a dissimilar distribution than the i you are running.

$ cd home:dmacvicar/gqlplus $ osc build openSUSE_Leap_42.2 ...

When you build a package in the Open Build Service, you will find out that, in improver to the automated deportment that inject dependencies, at that place are several checks being done to the package.

These checks are very detailed. Just this is the only way to ensure quality and consistency when a product is assembled from thousands of sources by hundreds of contributors.

The spec-cleaner tool tin assistance yous keeping your spec file in shape:

$ spec-cleaner -i gqlplus.spec

For example, information technology can help y'all converting BuildRequires: foo-devel dependencies to BuildRequires: pkgconfig(foo) . If a -devel package installs a pkg-config module, a Provides: pkgconfig(foo) is automatically injected. If the build process (./configure or Makefile) uses pkg-config to observe the software, it makes more sense and it is closer to reality to depend on pkgconfig(foo) beingness present, regardless which -devel package provides it.

You tin can get more information virtually how to fix post-build checks in the openSUSE Packaging Checks page at https://en.opensuse.org/openSUSE:Packaging_checks.

Until at present you left the %changelog section empty. Some distributions write the history of the packet to the changelog. SUSE-flavored distributions go on the changelog in a split .changes file. To chop-chop generate or update information technology, y'all can use osc vc in the directory containing the spec file and the sources.

Permission is granted to re-create, distribute and/or modify this document nether the terms of the GNU Gratuitous Documentation License, Version 1.2 or (at your selection) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled "GNU Complimentary Documentation License".

SUSE, the SUSE logo and YaST are registered trademarks of SUSE LLC in the United States and other countries. For SUSE trademarks, run into http://world wide web.suse.com/visitor/legal/. Linux is a registered trademark of Linus Torvalds. All other names or trademarks mentioned in this document may be trademarks or registered trademarks of their respective owners.

Documents published as part of the SUSE All-time Practices serial take been contributed voluntarily by SUSE employees and tertiary parties. They are meant to serve equally examples of how particular actions can exist performed. They have been compiled with utmost attention to detail. All the same, this does not guarantee consummate accuracy. SUSE cannot verify that actions described in these documents do what is claimed or whether deportment described accept unintended consequences. SUSE LLC, its affiliates, the authors, and the translators may not be held liable for possible errors or the consequences thereof.

Below we draw your attending to the license under which the manufactures are published.

Copyright (C) 2000, 2001, 2002 Gratuitous Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to re-create and distribute verbatim copies of this license document, but changing information technology is not allowed.

0. PREAMBLE #Edit source

The purpose of this License is to make a manual, textbook, or other functional and useful certificate "free" in the sense of liberty: to assure anybody the constructive freedom to copy and redistribute it, with or without modifying it, either commercially or not-commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made past others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves exist free in the same sense. Information technology complements the GNU Full general Public License, which is a copyleft license designed for free software.

We have designed this License to use it for manuals for free software, considering free software needs gratis documentation: a free plan should come with manuals providing the aforementioned freedoms that the software does. But this License is not limited to software manuals; information technology tin can exist used for any textual piece of work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is educational activity or reference.

1. APPLICABILITY AND DEFINITIONS #Edit source

This License applies to any transmission or other piece of work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a earth-broad, royalty-free license, unlimited in elapsing, to use that work under the weather condition stated herein. The "Document", beneath, refers to whatever such transmission or work. Whatsoever member of the public is a licensee, and is addressed as "you lot". You accept the license if you copy, alter or distribute the work in a fashion requiring permission nether copyright law.

A "Modified Version" of the Document means any work containing the Certificate or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front end-affair department of the Certificate that deals exclusively with the relationship of the publishers or authors of the Document to the Certificate's overall subject (or to related matters) and contains cypher that could autumn directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain whatsoever mathematics.) The relationship could exist a matter of historical connection with the discipline or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are sure Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a department does non fit the in a higher place definition of Secondary then it is not allowed to be designated as Invariant. The Certificate may contain zero Invariant Sections. If the Document does non identify any Invariant Sections then there are none.

The "Cover Texts" are sure short passages of text that are listed, as Front end-Comprehend Texts or Back-Cover Texts, in the find that says that the Document is released under this License. A Front-Cover Text may exist at most v words, and a Back-Embrace Text may exist at nearly 25 words.

A "Transparent" copy of the Document ways a auto-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the certificate straightforwardly with generic text editors or (for images equanimous of pixels) generic paint programs or (for drawings) some widely bachelor cartoon editor, and that is suitable for input to text formatters or for automatic translation to a diverseness of formats suitable for input to text formatters. A copy fabricated in an otherwise Transparent file format whose markup, or absenteeism of markup, has been bundled to thwart or discourage subsequent modification past readers is non Transparent. An prototype format is non Transparent if used for any substantial amount of text. A re-create that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent paradigm formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can exist read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not mostly available, and the machine-generated HTML, PostScript or PDF produced past some word processors for output purposes only.

The "Title Page" means, for a printed book, the title folio itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which practice not have any title page as such, "Title Page" means the text nigh the most prominent appearance of the piece of work's championship, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in some other language. (Hither XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only equally regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING #Edit source

Y'all may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice proverb this License applies to the Document are reproduced in all copies, and that you lot add no other conditions whatever to those of this License. You may not utilize technical measures to obstruct or control the reading or further copying of the copies you brand or distribute. However, yous may accept bounty in exchange for copies. If you distribute a large enough number of copies you must also follow the weather condition in section 3.

You may also lend copies, under the same conditions stated to a higher place, and you lot may publicly display copies.

iii. COPYING IN QUANTITY #Edit source

If you publish printed copies (or copies in media that normally have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Embrace Texts, yous must enclose the copies in covers that carry, clearly and legibly, all these Comprehend Texts: Front-Comprehend Texts on the front embrace, and Back-Cover Texts on the back cover. Both covers must too conspicuously and legibly identify you as the publisher of these copies. The front end encompass must present the full title with all words of the championship every bit prominent and visible. Yous may add other material on the covers in add-on. Copying with changes limited to the covers, every bit long as they preserve the title of the Document and satisfy these weather, tin be treated every bit verbatim copying in other respects.

If the required texts for either cover are also voluminous to fit legibly, you should put the first ones listed (every bit many every bit fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If yous publish or distribute Opaque copies of the Certificate numbering more than 100, you must either include a automobile-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If yous employ the latter pick, you lot must take reasonably prudent steps, when yous begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus attainable at the stated location until at to the lowest degree 1 yr after the last fourth dimension you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you lot contact the authors of the Document well earlier redistributing any large number of copies, to give them a gamble to provide yous with an updated version of the Document.

iv. MODIFICATIONS #Edit source

You may copy and distribute a Modified Version of the Certificate under the conditions of sections 2 and three in a higher place, provided that y'all release the Modified Version under precisely this License, with the Modified Version filling the part of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of information technology. In add-on, y'all must practise these things in the Modified Version:

Use in the Title Folio (and on the covers, if any) a championship singled-out from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History department of the Document). Y'all may use the aforementioned title as a previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at to the lowest degree five of the chief authors of the Document (all of its main authors, if it has fewer than five), unless they release you from this requirement.
State on the Title page the name of the publisher of the Modified Version, every bit the publisher.
Preserve all the copyright notices of the Document.
Add together an appropriate copyright notice for your modifications next to the other copyright notices.
Include, immediately later on the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the grade shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Comprehend Texts given in the Document's license notice.
Include an unaltered copy of this License.
Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the championship, twelvemonth, new authors, and publisher of the Modified Version as given on the Title Folio. If there is no section Entitled "History" in the Certificate, create ane stating the title, year, authors, and publisher of the Document as given on its Championship Page, then add an detail describing the Modified Version equally stated in the previous sentence.
Preserve the network location, if whatever, given in the Certificate for public access to a Transparent copy of the Certificate, and as well the network locations given in the Document for previous versions it was based on. These may be placed in the "History" department. You lot may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
For any section Entitled "Acknowledgements" or "Dedications", Preserve the Championship of the department, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Certificate, unaltered in their text and in their titles. Section numbers or the equivalent are non considered role of the section titles.
Delete whatever department Entitled "Endorsements". Such a department may non be included in the Modified Version.
Practise not retitle any existing section to be Entitled "Endorsements" or to conflict in title with whatsoever Invariant Section.
Preserve any Warranty Disclaimers.

If the Modified Version includes new front-thing sections or appendices that qualify equally Secondary Sections and contain no material copied from the Document, you may at your selection designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version'southward license notice. These titles must exist distinct from any other section titles.

You may add a department Entitled "Endorsements", provided it contains nothing simply endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization equally the authoritative definition of a standard.

You may add a passage of up to five words equally a Front-Cover Text, and a passage of up to 25 words as a Dorsum-Comprehend Text, to the cease of the listing of Cover Texts in the Modified Version. Only ane passage of Front end-Cover Text and one of Dorsum-Cover Text may exist added past (or through arrangements made by) any one entity. If the Document already includes a encompass text for the aforementioned comprehend, previously added by yous or by arrangement made by the aforementioned entity yous are acting on behalf of, you may not add another; but you may replace the quondam 1, on explicit permission from the previous publisher that added the sometime one.

The author(s) and publisher(s) of the Document exercise not by this License give permission to employ their names for publicity for or to affirm or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS #Edit source

Y'all may combine the Document with other documents released under this License, under the terms defined in section 4 higher up for modified versions, provided that yous include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all equally Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work demand simply incorporate one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the aforementioned name simply different contents, make the title of each such section unique past calculation at the end of it, in parentheses, the proper name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the department titles in the list of Invariant Sections in the license notice of the combined piece of work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS #Edit source

Y'all may make a collection consisting of the Document and other documents released under this License, and supervene upon the individual copies of this License in the diverse documents with a single copy that is included in the drove, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

Yous may excerpt a unmarried certificate from such a collection, and distribute it individually under this License, provided yous insert a re-create of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS #Edit source

A compilation of the Certificate or its derivatives with other split up and contained documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation'south users beyond what the individual works permit. When the Document is included in an amass, this License does not utilize to the other works in the aggregate which are non themselves derivative works of the Document.

If the Cover Text requirement of section three is applicable to these copies of the Document, and then if the Document is less than one half of the entire amass, the Document's Cover Texts may be placed on covers that bracket the Document inside the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

viii. TRANSLATION #Edit source

Translation is considered a kind of modification, and so you may distribute translations of the Document under the terms of section four. Replacing Invariant Sections with translations requires special permission from their copyright holders, merely you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you lot also include the original English language version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Certificate is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Championship (section ane) will typically require irresolute the actual title.

nine. TERMINATION #Edit source

You may not re-create, modify, sublicense, or distribute the Certificate except every bit expressly provided for under this License. Whatsoever other endeavour to re-create, modify, sublicense or distribute the Document is void, and will automatically stop your rights nether this License. However, parties who have received copies, or rights, from you lot under this License will non have their licenses terminated and so long as such parties remain in full compliance.

ten. FUTURE REVISIONS OF THIS LICENSE #Edit source

The Costless Software Foundation may publish new, revised versions of the GNU Gratuitous Documentation License from time to time. Such new versions will exist like in spirit to the present version, merely may differ in detail to address new problems or concerns. Run across http://world wide web.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Certificate specifies that a particular numbered version of this License "or any later version" applies to it, you lot have the choice of following the terms and weather either of that specified version or of any later version that has been published (not equally a draft) past the Free Software Foundation. If the Document does non specify a version number of this License, you may choose any version ever published (non as a draft) by the Complimentary Software Foundation.

Annex: How to use this License for your documents #Edit source

Copyright (c) YEAR YOUR NAME. Permission is granted to re-create, distribute and/or modify this document under the terms of the GNU Complimentary Documentation License, Version i.2 or any later version published by the Costless Software Foundation; with no Invariant Sections, no Front-Comprehend Texts, and no Dorsum-Comprehend Texts. A copy of the license is included in the section entitled "GNU  Costless Documentation License".

If you lot have Invariant Sections, Front-Comprehend Texts and Back-Cover Texts, supplant the "with...Texts". line with this:

with the Invariant Sections existence LIST THEIR TITLES, with the Front-Cover Texts existence LIST, and with the Back-Cover Texts beingness Listing.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of plan lawmaking, we recommend releasing these examples in parallel nether your pick of free software license, such every bit the GNU General Public License, to allow their utilise in free software.

Source: https://documentation.suse.com/sbp/all/html/SBP-RPM-Packaging/index.html

Posted by: baileyjakfam.blogspot.com