Building an RPM package for Rosa Linux in practice

If you have been using the Linux operating system for a long time and even know a little about programming, sooner or later you may need to compile the program from the source code. Maybe the necessary program will not appear in the distribution repositories. Or the old version program in these repositories, and you need the latest one. Or maybe you created a new program and want to share it with other users.

Of course, you can install the program according to the instructions that came with the source code. But then you will need to manually manage the program files and monitor its dependencies. It is much better to build a package with the program and use the application manager built into the operating system.

I hope this article helps you quickly figure out how to build an RPM package for Rosa Linux or for another distribution that uses the RPM package manager (Mandriva, RedHat). Or at least tell me where to look for information.

Here I will show how to create RPM packages on my local computer, using a simple example. We will build the xkb-switch program in the Rosa Linux operating system. We will take the source code of the program from GitHub .

The article is divided into many short parts, so the table of contents is under the spoiler

A bit about Rosa Linux

Rosa Linux is a distribution created and supported by Russian developers . It is based on Mandriva , but with some features. I am using the 32-bit version of Rosa Fresh R8 , which was released in 2014. Now the R8 version is no longer supported by developers (repositories for it are not updated), but it works well on my laptop, so I do not want to install a new version.

Rosa Fresh R8 Uses the KDE4 desktop. All versions of the distribution package use rpm

and urpm

managers to manage packages with applications, and the corresponding commands are rpm

, urpmi

, urpme

, urpmq

, urpmf

.

The principles for building software packages are usually rarely changed within the same Linux distribution family. Therefore, what is described in this article should work in all versions of Rosa distributions.

Building packages on Rosa Linux is a bit simpler than on some other RPM- based distributions. Some points are automated and do not need to be configured.

A bit about xkb-switch

I liked the idea of using the plugin for the Vim text editor - xkbswitch , about which there is an article on Habré . It automatically switches the keyboard layout to English when you exit the input mode, and vice versa - to the one on which the text was entered last time - if you enter the input mode again. For this plugin to work, you need the xkb-switch program, which allows you to switch the keyboard layout from the command line and from plugins for the Vim editor. This program was not in the Rosa Linux R8 repositories (and most likely no one will add it, because the distribution is already old, and the xkb-switch program is not very popular).

Setting up, finalizing, checking the program

Often you need to configure the compilation of the program to work correctly in a particular distribution or even for a specific system. It happens that a program needs to be built with other options or with the support of some special driver. Or maybe you want to fix errors in the program code or just check if it works. To do this, it is better to copy the source code to your computer before building the RPM package, try to compile it, and check how the compiled program works.

If you are sure that you will not need to modify the project files, then you can use the original source code from the project site and immediately proceed to build the package. But if you need to change the compilation settings, it is usually much easier to change the file in the source folder (the so-called makefile ) than to then deal with the compilation command options and the macro's internal device for the spec file.

Checking the source code without your profile on GitHub

If you decide to work with the source code or project compilation settings, but you don’t have your own profile on GitHub or don’t want to use it, you can simply download and unzip the source code. In our case, it might look like this (I use the ~/Projects/cpp

folder for C ++ source code):

 cd ~/Projects/cpp git clone https://github.com/ierton/xkb-switch.git

This will create the ~/Projects/cpp/xkb-switch

folder containing the source code. Of course, instead of using git

you can download the archive with the program and unzip it.

From the README.md

file in the project folder, it is easy to guess that the cmake

utility is used to build the program. Therefore, if you need to change the compilation settings, in our case they are in the CMakeLists.txt

file. And we just try to compile the program and check if it works. What commands you need to use for this is written in the same README.md

file in the root of the project.

 cd xkb-switch mkdir build && cd build cmake .. make ./xkb-switch #         ./xkb-switch -l #       ./xkb-switch -s ru #       (  )

After that, in order to use the changed project, you will have to clear or delete the build

folder from the project and pack the source code into the archive. It might look like this:

 cd ~/Projects/cpp/xkb-switch rm -rf ./build cd ~/Projects/cpp zip -r xkb-switch.zip xkb-switch

The xkb-switch.zip

file xkb-switch.zip

then need to be used to build the package.

Verification with saving the project to your GitHub profile

I assume that anyone who reads this section is at least a little familiar with working with git and has already set up a profile on GitHub . I think this method is the best, so the rest of the article will imply that it is used, unless otherwise stated.

First you need to fork the original project into your GitHub . After that, as in the previous method, we clone the project to our computer, but from our repository (in my case, the username is alexandersolovyov ):

 cd ~/Projects/cpp git clone https://github.com/alexandersolovyov/xkb-switch.git

To add any changes, it is better to use a new branch. Then, if desired, it will be possible to use different versions of the program. And it will also be possible to propose changes to the project author using pull-requests. For example, if you decide to fix the CMakeLists.txt

file a little, before that you need to create a new branch with:

 git branch cmake_corrections

After the changes are made, checked and added to the branch (using git commit -am " "

), you can add a new branch to your GitHub:

 git push origin cmake_corrections

After that, you can make a pull-request, if necessary.

You can make a link to the original repository:

 git remote add ierton https://github.com/ierton/xkb-switch.git

And then update the main branch of your repository so that it matches the original:

 git pull ierton master

The program code corresponding to the corrected branch can be used when building the RPM. To do this, you will need to specify the address to the archive in the form in the spec file:

 Source0: https://github.com/-/-/archive/---.zip

Prepare the "workplace" to create a package

First you need to create a directory structure. All assembly takes place in the rpmbuild

folder in the rpmbuild

's home folder. Create the initial directory structure and go to the folder for spec files:

 mkdir -p ~/rpmbuild/SPECS && cd ~/rpmbuild/SPECS

For Rosa Linux, this is enough: the remaining folders will be created automatically.

Another distribution may use a different file location to build the package. And maybe you’ll have to create the entire folder hierarchy manually. Look for information for your distribution if you are not using Rosa Linux. For example, this might look like this in Red Hat .

If the package was built with errors, then all files created by the rpmbuild

command rpmbuild

not deleted - the same as with a successful build. We will try to collect the package many times, and the files remaining after the last time will interfere. Therefore, it is better to make a simple script that will help to remove them quickly. Create a cleanup.sh file and place it in the ~/rpmbuild/SPECS

. Here are its contents:

 !#/bin/sh rm -rf ~/rpmbuild/BUILD/* rm -rf ~/rpmbuild/BUILDROOT/* rm -rf ~/rpmbuild/RPMS/* rm -rf ~/rpmbuild/SRPMS/*

Of course, it’s better to add execution rights for it using the chmod u+x cleanup.sh

.

If you want to collect a package from files that are on the local computer — if you are not using GitHub and made changes to the project files, or if you want to create a package from your own program that is stored only on your computer — you need to pack the project into an archive ( e.g. .zip

, .tar

or .tar.gz

) and put it in the SOURCES

folder. For example, like this:

 cd ~/Projects/cpp/ zip -r xkb-switch.zip xkb-switch mkdir -p ~/rpmbuild/SOURCES cp xkb-switch.zip ~/rpmbuild/SOURCES/

Let's start creating a spec file

The basis for building an RPM package is the so-called speck file . This file contains the instructions for the rpmbuild

program (or rather rpm

) necessary for building the package.

Create the xkb-switch.spec

file in the ~/rpmbuild/SPECS/

. The easiest way to start is with a template that can be found on the Template Spec Files website.

From the README

on the xkb-switch project page, it is known that the program is compiled using the cmake

utility. Therefore, we will select the Spec file for a program built using CMake and copy the entire template to our spec file. Of course, in order to properly assemble our RPM package, this template needs to be changed a lot, which we will do.

A bit about spec file syntax

The spec file syntax allows you to add bash-style comments.
You can use spaces as the spaces between the values on the same line to create the appearance of even columns, but the documentation strongly recommends using a tab character (one or two as long as necessary to keep the columns even). Note: in all code examples in this article, only spaces are used, so it’s better not to copy all the text from here to your spec file, but print it yourself.

Option fields consist of a special option name with a colon and the next value through tabs (or spaces). The case of characters in field names does not matter. For example:

  Name: xkb-switch

If the word is preceded by the %

symbol (for example, %description

), then this is a special keyword. It can be a command, macro, or script call. Then after it the parameters that he uses can be indicated. And there are keywords that indicate the beginning of a block of commands or options. Then, parameters can be indicated next to it, and on the next lines there should be commands or a list of options that I described in the previous paragraph. After such a block, an empty line should be left.
To use the value of a constant, you need to insert a construction of the form %{_}

. Its value can be predefined, or it can be determined by an option (for example, Name: xkb-switch

) or using the %define

keyword. All these constants are also considered macros. Their use will be discussed in more detail below.

Spec file header

In the spec file, the header is always written first. This is a list of options that apply to the main RPM package. When the package is ready, almost all of this information will be displayed when viewing its description. Here is what the individual lines indicate:

Summary:

A short description of the package. I spied the description in the README.md

file in the xkb-switch project: Query and change XKB layout state

.

Name:

The name of the package. In our case, this is xkb-switch

.

Version:

Program version. To find out, it's best to look at the CMakeLists.txt

file in the project root folder. Of course, you need to take the file from the copy of the project that will be used for assembly. If you use the original project, you can open the file directly on its GitHub page . As you can see, the version is composed of MAJOR_VERSION

, MINOR_VERSION

and RELEASE_VERSION

. I used the program version 1.6.0

.

Release:

The version number of the package itself. Displays which time a package with a program of the same version is being assembled. In our case, this is “1”, since no one has ever assembled a program of this version. In the ideal case, if we already tried to build the package and the assembly reached the end (even if there were errors), then after each new attempt you need to increase this number by 1 and at the same time do not delete the old assembled packages from the rpmbuild/RPMS

and rpmbuild/SRPMS

: Next, new packages with a new build number will be created. Perhaps this should be done if you use a special server for assembly. We use our computer and instead we will clean the folders. If a package with a program of this version is already in the repositories of the Linux distribution, but you compile with other settings, then it is better to specify the release number by 1 more than that package.

License:

The short name of the license under which the program is distributed. According to the rules of Rosa Linux, you can only build packages with a license that allows free distribution. README.md

can find out from the README.md

file that the license is GNU GPLv3 . So we write: GPLv3+

.

Group:

The group or category to which the program belongs. Using these groups, programs are sorted in the application launch menu and in the window program manager (“Add or Remove Programs”). The list of groups for Rosa Linux can be found here . I think Development\X11

is best for us, since the program is related to X11 and is needed mainly for creating scripts and plugins for Vim.

URL:

Internet address where you can download the original source code of the program. It will be specified when viewing RPM package information. This item is optional, but we will indicate: https://github.com/ierton/xkb-switch

Source0:

The name of the archive file containing the source code, or the Internet address where it can be downloaded. If you specify an address on the Internet, then during the first build the file will be downloaded to ~/rpmbuild/SOURCES/

. If such a file already exists, it will no longer be downloaded, that is, the rpmbuild

program will use only the file name indicated at the end of this URL. You can specify just the file name, but then it will need to be placed in the ~/rpmbuild/SOURCES/

folder manually. It’s better to provide the address of your copy of the project on GitHub. I used the file https://github.com/alexandersolovyov/xkb-switch/archive/master.zip

. You can specify several different sources to collect the sources from several archives with the help of one speck file. Then in the name of the option to add each subsequent archive, the number should increase ( Source1

, Source2

, etc.). These file addresses are not visible when viewing RPM package information.

BuildRequires:

Packages required to build the program. The template cmake

. The CMakeLists.txt

file indicates that the minimum version of CMake for assembly should be no lower than 2.6 , so it is better to specify cmake >= 2.6

. You can add other packages, each of them on a separate line, using the separate BuildRequires:

option. The list of packages needed for assembly can be found by reading the project’s README

and carefully looking at the CMakeLists.txt

file (especially the FIND_PACKAGE

, TARGET_LINK_LIBRARY

, FIND_PROGRAM

). Then you need to find the correct package name in the repositories using the command urpmq -a __

. In our case, the compilation settings file ( CMakeLists.txt

) already contains lines that check for the presence of the necessary packages in the system. But it’s better to specify the whole list here too:

 # CMake  2.6   BuildRequires: cmake >= 2.6 #  C/C++ BuildRequires: gcc #    libxkbfile BuildRequires: libxkbfile-devel #   X11   libxkbfile, #  libx11-devel   . #    man: BuildRequires: xz

Requires :, Provides:

These options are not in the sample, but sometimes they can come in handy. They establish dependencies between packages. The Provides

option specifies the features provided by the package being built. This can be the name of the C header file or the name of a dynamic library, or some special function. And the Requires

option indicates which Capabilities of other packages the package depends on. The package manager ( rpm

, urpm

, or another that is used in your distribution), when looking for dependencies, searches for exactly these Features , and not the names of the packages. Therefore, for Provides

it is better to indicate the version of the provided Opportunity , and for Requires

- which versions of the provided Opportunity are suitable. The version is indicated by the signs >=

, =

, or <=

, surrounded by spaces. Usually, all the Requires

options are indicated first, then Provides

, one feature name per line - the same as for BuildRequires:

Typically, when building packages on Rosa Linux, dependencies are automatically recognized, and these options rarely need to be specified.

% description

This block is no longer part of the header, but is associated with it. He will add a full description of the program to the RPM package. An empty line should be left after it. The description may be as follows:

 %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley.

Lines from the template starting with %files

and %find_lang

are needed only if you build an application with support for several languages, so delete them.

Further, after the dividing line-comment, followed by commands and macros that must be completed before packing the files. All these commands are divided into blocks defined using special keywords.

Source preparation

The first is the %prep

block, which indicates the commands to prepare for compilation. In it is the macro command %setup

. She runs a script that does the following:

It downloads archives with source program files indicated by options with names of the form SourceX:

in the file header (we have only Source0:

. If the file has already been downloaded or only the file name is specified, then nothing is downloaded.
Downloaded files are saved in the ~/rpmbuild/SOURCES/

folder.
Unpacks these archives into the ~/rpmbuild/BUILD/

folder.
Goes to the folder with the unpacked files.

Its -q

option specifies that less information be displayed at runtime.

You can immediately try to build the package, stopping after executing the %prep

block:

 rpmbuild -bp ~/rpmbuild/SPECS/xkb-switch.spec

To build, use the rpmbuild

command. If your system does not have this command, then you can use rpm

with the same options rpmbuild

: rpmbuild

is its limited synonym, which is intended only for building packages. All build commands must be executed as a regular user (not as root

and without the sudo

). A description of all rpmbuild

options can be seen by running man rpmbuild

. You can also see the list of folders in which macros and other files used by this command are located, in case you want to understand in more detail the order of the rpmbuild

.

As a result, we get the error message: xkb-switch-1.6.0: No such file or directory

. The command output shows that after unpacking the archive, the script tries to go to the ~/rpmbuild/BUILD/xkb-switch-1.6.0

folder, which is not there. Running the command

 ls ~/rpmbuild/BUILD/

We see that the xkb-switch-master

folder is located there. It must be specified with the %setup

command using the -n

option. As a result, the %prep

block in the spec file should look like this:

 %prep %setup -q -n xkb-switch-master

Run our ~/rpmbuild/SPECS/cleanup.sh

to clear the BUILD

folder and try building the package again, ending with the %prep

block. Now we see that the last message displays exit 0

. This means that the block is executed without errors. You can move on.

Compilation

Compilation of the source code is performed by the %build

block. The project’s README

says that compilation is done by cmake ..

and make

, but our spec file uses the same name macros. This is correct: this way the commands will be executed with all the transitions to the folders and the options that are needed for proper compilation. Leave it as it is, clear the folders and build to the %build

point inclusive:

 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bc ~/rpmbuild/SPECS/xkb-switch.spec

At the end of the output we see exit 0

: everything was done without errors.

In general, it is not necessary to use only macros in command blocks. You can add any shell commands (that is, bash or zsh, or whatever you have there). The rpmbuild

command moves through folders during build, so you need to add the transition to the correct working folder before your command. In these shell commands, you can use the spec file constants - as elsewhere in this file. ( .)

- , , , %build

shell .

, , . cmake

, , , %cmake

- , , . ( — CMakeLists.txt

). , .

, . %install

, , , ~/rpmbuild/BUILDROOT/__-buildroot/

.

__

, Name:

-, ( Version:

-), ( Release:

-), , .

README

, make install

, build

. - - %makeinstall_std -C build

, . ( , ):

 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bi ~/rpmbuild/SPECS/xkb-switch.spec

, RPM. - , .

, - . , ~/rpmbild/BUILDROOT/

. ( , , tree

, - Linux.) , , .debug

. , , : .

, , %files

-. , , . .

%files

-. , . Rosa Linux %prep

( - ). , , , , — . - (, , ).

%files

, RPM. , :

 %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz

-. , , /usr/lib/rpm/macros

. , %{_bindir}

, %{_libdir}

— , %{_mandir}

— man. %{name}

%{version}

Name:

Version:

-.

 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec

… 2 1 . rpmlint

, . , , Rpmlint Errors , :

`xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1`

Error: The version in the library package name is not specified correctly.

`xkb-switch.i586: E: executable-in-library-package (Badness: 1) / usr / bin / xkb-switch`

Error: the library package contains an executable file.

`xkb-switch.i586: W: devel-file-in-non-devel-package / usr / lib / libxkbswitch.so`

Warning that a development package file ( -devel

) was found in a package that was not intended for development.

All clear? I don’t think so. Let's take a closer look at what's happening here.

What is rpmlint

Rosa Linux rpmbuild

rpmlint

, . rpmlint

, , . , Rosa Linux ( , rpmlint

) .

, , . ~/rpmbuild/RPMS/_/

rpmlint -i __

.

By the way, if you downloaded the ready-made RPM package on the website of a project, then before installing such a package, you can check how correctly it is built for Rosa Linux using the same command rpmlint -i __

.

Types of RPM Packages for Rosa Linux

Packages for Rosa Linux are divided into 6 types. In the ideal case, each assembled package should correspond to only one of these types.

Executable package

It is binary. Contains only a binary file or script intended directly for execution. The files of these packages are most often installed in a folder /bin/

or in /usr/bin

. May also contain links - for the possibility of calling the program using several different names. The name of the package corresponds to the name of the program. Such packages are often library dependent.

Library

Contains compiled files of the dynamically connected ("shared", "shared") library used by programs. Usually this is the library file itself, whose name ends with the version, and a link to this file, whose name ends with the first version number. For example, the library libxkbfile

version 1.0.2 it will file libxkbfile.so.1.0.2

and link to it libxkbfile.so.1

. The very name of the library package, by which it is recognized in the repository of the installer, ends with the first version number and begins with the prefix lib

. The library has the libxkbfile

correct name -libxkbfile1

. This is due to the fact that usually the first version number changes only with incompatible library changes, and so it will be possible to install several packages with a library of different versions if some programs use the old version of the library and others use a newer version.

Package for developers

Files necessary for compiling programs that use the library, but unnecessary for the work of ready-made programs. For simple C / C ++ programs , this is a link to the library file, but without versions in the name (for example libxkbfile.so

), as well as header files (with the extension .h

). Name of the package ends with -devel

, for example: libxkbfile-devel

. During installation, it always depends on the appropriate library. For example, a package libxkbfile-devel

depends onlibxkbfile1

.

Source Code

Rosa Linux repositories have RPM packages that contain source code for some programs - mostly only those that really need to be rebuilt. The names of these packages end with -src

or -source

(for example, apache-source

). rpmbuild

always creates such a package automatically and puts it in ~/rpmbuild/SRPMS/

.

Debugging Symbols

This is information that can be used to debug a finished program. It associates locations in compiled files with source code. Such packages are rpmbuild

automatically created by the team , an ending is assigned to their name -debuginfo

. I did not find such packages in Rosa Linux repositories.

Documentation

Rosa Linux repositories have documentation packages for various programs and libraries. I (for now) do not know the features of building such packages. Their names usually end in doc

: for example libx11-doc

, java-1.7.0-openjdk-javadoc

. By the way, almost all of them are made in the style of websites, and in order to view them, it is best to open a browser, go to the address file:///usr/share/doc/

and select the desired folder and file.

Our result

Now everything has become clearer.

Our package xkb-switch

contains a file libxkbswitch.so

, which, according to the rules, must be contained in a package for development . Therefore, issued a message that the development of the file is not in the package for the development of: xkb-switch.i586: W: devel-file-in-non-devel-package /usr/lib/libxkbswitch.so

.
, /usr/lib/libxkbswitch.so.1

/usr/lib/libxkbswitch.so.1.6.0

. , . : xkb-switch.i586: E: executable-in-library-package (Badness: 1) /usr/bin/xkb-switch

.
, (1). : xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1

.

, rpmlint

, . . xkb-switch , libxkbswitch.so.1.6.0

, Vim . xkb-switch , C C++ . RPM- .

- xkb-switch

 Summary: Query and change XKB layout state Name: xkb-switch Version: 1.6.0 Release: 1 License: GPLv3+ Group: Development/X11 URL: https://github.com/ierton/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley. %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build

— , . , , xkb-switch

3 : , . :

/usr/bin/xkb-switch

/usr/share/man/man1/xkb-switch.1.xz

,
— /usr/lib/libxkbswitch.so.1

/usr/lib/libxkbswitch.so.1.6.0

,
— /usr/lib/libxkbswitch.so

.

-. , ,

- Maximum RPM . - libxkbfile Rosa Linux .

— - libxkbfile . - :

 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch

%define

. , ( ) — , . , %{major}

1

, .

%mklibname

«lib», , — ( ). %{libname}

«lib» + «xkbswitch» + ( %{major}) = libxkbswitch1

— .

-d

%mklibname

-devel

. %{develname}

libxkbswitch-devel

— .

Version:

 Version: %{major}.6.0

, -.

- . . :

 Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley.

- . - , - ( rpm ). %package

. -. , -. Version

, Summary

, Group

. Provides

Requires

, . Name

: , %package

.

. %description

— , %package

.

Rosa Linux - %description

-. libxkbswitch1

:

 %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'.

-n

%package

%description

, . - , xkb-switch-libxkbswitch1

. libxkbswitch1

. .

 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'.

, . %files

.

, , %package

, %description

%files

. , %description

- . , , — xkb-switch

.

- Rosa Linux %files

, %prep

. :

 %files %{_bindir}/%{name} %{_mandir}/%{name}.1.xz %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %files -n %{develname} %{_libdir}/libxkbswitch.so

, :

xkb-switch

~/usr/bin/xkb-switch

~/usr/share/man/man1/xkb-switch.1

,
libxkbswitch1

~/usr/lib/libxkbswitch.so.1

~/usr/lib/libxkbswitch.so.1.6.0

,
libxkbswitch-devel

~/usr/lib/libxkbswitch.so

.

cleanup.sh

rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec

. 3 :

 libxkbswitch1.i586: W: no-documentation libxkbswitch-devel.i586: W: no-documentation libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch

, . , . . Let's try to figure it out.

, , , README.md

. %files

— %doc

:

 %doc README.md

. %doc

— . ~/rpmbuild/BUILD/xkb-switdh-master/README.md

.

: libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch

. , libxkbswitch-devel

libxkbswitch

.

rpm -qp --

. :

 [user@pc ~] $ cd ~/rpmbuild/RPMS/i586/ [user@pc ~/rpmbuild/RPMS/i586] $ ls libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-debuginfo-1.6.0-1-rosa2014.1.i586.rpm [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch.so.1 libxkbswitch1 = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libxkbswitch) libxkbswitch-devel = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libX11) devel(libgcc_s) devel(libstdc++) devel(libxkbfile) rpmlib(PayloadIsXz) <= 5.2-1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.11) libstdc++.so.6(GLIBCXX_3.4.20) libstdc++.so.6(GLIBCXX_3.4.9) libxkbswitch.so.1 rpmlib(PayloadIsXz) <= 5.2-1

, libxkbswitch1

libxkbswitch.so.1

libxkbswitch1

. xkb-switch

libxkbswitch.so.1

, libxkbswitch-devel

libxkbswitch1

. , %package

libxkbswitch-devel

. :

 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version}

, … . libxkbswitch-devel

, , . , , rpmbuild

.

-, ( README.md

), — :

 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch # Main package. Automaticaly requires libxkbswitch and libxkbswitch-devel Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley. # libxkbswitch %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'. # libxkbswitch-devel %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version} %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'. # xkb-switch %files %{_bindir}/%{name} %{_mandir}/man1/%{name}.1.xz # libxkbswitch1 %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %doc README.md # libxkbswitch-devel %files -n %{develname} %{_libdir}/libxkbswitch.so %doc README.md #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build

, RPM Rosa Linux ( ). , -. , — , , rpmrc , ABF , — .

— , -, - , — .

rpmbuild -bp specfile.spec

Run preparation (% prep).

rpmbuild -bc specfile.spec

Run compilation (% build) and all previous actions.

rpmbuild -bi specfile.spec

Perform a pseudo- install (% install) and all previous steps.

rpmbuild -ba specfile.spec

Build packages completely.

Checking the finished package

rpmlint -i package_file_name.rpm

General check - how well the package was built.

rpm -qp --provides package_filename.rpm

Check which "features" are provided by the package.

rpm -qp --requires package_filename.rpm

Check which "capabilities" of other packages this package depends on.

rpm -qpl package_file_name.rpm

List of files contained in the package.

rpm -qpi package-file-name.rpm

Information about the package (from the "header" of the spec file or from the % package block ).

, p

. , Rosa Linux, . urpmq

, rpm -q

. , urpmq -l _

, urpmq --requires _

.

( )

Building RPMs — Quick Start — RPM Rosa Linux.
RPM — , , . .
Maximum RPM — rpm

RPM- RedHat Linux. , Rosa Linux. .
Template Spec Files — .spec

. , -.
Automatic Build Farm (ABF) — Rosa Linux. , , , .spec

. -.
Rpmlint Errors — , rpmlint

.
Packaging Group — Rosa Linux.
Rosa Linux .

All Articles