16.9. RPC packet formats In Fig. Figure 16.5 shows the format of an RPC request in a TCP packet. Because TCP carries a stream of bytes and does not provide message boundaries, the application must provide a way to delimit messages. Sun RPC defines an entry as a request or a response, and each entry

Chapter 17. Creating packages and distributing programs More and more products - and primarily aspirin - are being produced in packaging that is protected to such an extent that the consumer can no longer use them. Dave Barry This chapter is about how to

27.1.2. IP and TCP Packet Structure The IP protocol is not connection oriented and therefore does not provide reliable data delivery. The fields described in Table 27.4 represent the IP header and are added to the packet when it is received from the transport

4.10.1. Packet filtering So, the main, but not the only task of a firewall is packet filtering. Linux already has a built-in Firewall, and you don't need to install it separately. More precisely, there are even two of them: iptables and ipchains. They allow you to control the traffic that passes through

14.12.1. Defragmentation of Packets Hackers carry out a lot of attacks on servers using fragmented packets. In Linux, you can have the OS merge incoming packets. If you have a monolithic kernel (without module support), then you need to write 1 in the file

Package format As already mentioned, the Mint distribution adopts the deb package format. Having been developed back in the last millennium for the Debian distribution, this format was inherited from it by Ubuntu, largely predetermining the success of the latter. And after it - and our luck

But it often happens that you need to build a package with the necessary options (enable support for mysql, postgresql or cyrus-sasl2, etc.) that are not in the rpm package supplied on the distribution disk. The way out of this situation is to build your own package.

To make it easier to build rpm packages, there is a package specially designed for this purpose - rpm-build.

# rpm -qi rpm-build Name: rpm-build Relocations: (not relocatable) Version: 4.3.3 Vendor: CentOS Release: 7_nonptl Build Date: Mon 21 Feb 2005 20:21:52 Install Date: Sat 09 Apr 2005 22: 14:57 Build Host: guru.build.karan.org Group: Development/Tools Source RPM: rpm-4.3.3-7_nonptl.src.rpm Size: 1576124 License: GPL Signature: DSA/SHA1, Sun 27 Feb 2005 00: 36:59, Key ID a53d0bab443e1821 Packager: Karanbir Singh

As can be seen from the description, this package contains a set of scripts and programs designed to build packages.

In order to assemble any package, you first need to download the so-called. The sources for building the package are usually files with the extension src.rpm. Sometimes, as in the case of courier-imap, a spec file is included in the source code.

The site www.rpmfind.net is very convenient for searching for rpm and src.rpm packages. For example, we found the package we needed - postfix, squid, etc. We can immediately find out which packages are needed to build it. Here is the standard package information page for both postix and squid. It also contains a checksum to verify the integrity of the package.

After we have received the sources and verified their integrity, we need to install the appropriate package.

# rpm -ivh postfix-2.2.8-1.2.src.rpm 1:postfix ################################ ###########

After performing this operation, the postfix sources and all the necessary parts, as well as scripts, were installed in /usr/src/redhat/SOURCES/, and the spec file (instructions for building the rpm package) in /usr/src/redhat/SPECS/.

# ls /usr/src/redhat/SOURCES/ pflogsumm-1.1.0.tar.gz postfix-etc-init.d-postfix postfix-2.1.1-config.patch postfix-hostname-fqdn.patch postfix-2.1.1 -obsolete.patch postfix-large-fs.patch postfix-2.1.5-aliases.patch postfix-pam.conf postfix-2.2.5-cyrus.patch postfix-sasl.conf postfix-2.2.8.tar.gz README- Postfix-SASL-RedHat.txt postfix-alternatives.patch # ls /usr/src/redhat/SPECS/ postfix.spec

This is the default file location when installing src.rpm. In principle, the names of the folders speak for themselves.

And so, in order to start building the package, you need to go to the folder with the spec file and run the following command

# cd /usr/src/redhat/SPECS/ # rpmbuild -ba --target=i686 postfix.spec Platforms to build: i686 Build for i686 platform Running (%prep): /bin/sh -e /var/tmp/rpm -tmp.82019 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 + /bin/gzip -dc /usr/src /redhat/SOURCES/postfix-2.2.8.tar.gz + tar -xf - + STATUS=0 + "[" 0 -ne 0 "]" + cd postfix-2.2.8 ++ /usr/bin/id - u + "[" 0 = 0 "]" + /bin/chown -Rhf root . ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo "Patch #1 (postfix-2.1.1-config.patch):" Patch #1 (postfix-2.1.1-config.patch): + patch -p1 -b --suffix .config -s ... ... ... Recorded by: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Recorded by: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686 .rpm Recorded by: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Executed (%clean): /bin/sh -e /var/tmp/rpm-tmp.73987 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

From the last lines you can see that the finished rpm package is called postfix-2.2.8-1.2.i686.rpm and is saved in the /usr/src/redhat/RPMS/i686/ folder, since when building the package we specified the --target=i686 key .

The actual assembly should not cause any problems. But what if we need to build a package with our own options, for example, enable mysql or sasl2 support, etc.? For these purposes, you will need to edit the spec file.

Let's look at part of the postfix spec file. It should be noted that postfix has a non-standard spec file, so to speak.

For example, we wanted to build postfix with MySQL support, to do this, at the very beginning we change %define MYSQL 0 to %define MYSQL 1. and run the command again

# rpmbuild -ba --target=i686 postfix.spec Platforms to build: i686 Build for i686 platform error: Unmet build dependencies: mysql-devel needed for postfix-2.2.8-1.2.i686

He writes to us that to build it we need to install the mysql-devel package. Please note that the version is not specified, this means that you can install any version that postfix supports or the package you need.

If you were building from source, you would have to find out on your own what packages are needed to build a given package. This is one of the advantages of building from src.rpm compared to tar.gz or tar.bz2.

Install the appropriate package

# rpm -ivh MySQL-devel-4.1.9-0.i386.rpm Preparing... ################################ ############## 1:MySQL-devel ############################### #############

And we restart the postfix assembly. This time we see that all the necessary packages for the build are installed and now we just need to wait for the build to finish.

# rpmbuild -ba --target=i686 postfix.spec Platforms to build: i686 Build for i686 platform Running (%prep): /bin/sh -e /var/tmp/rpm-tmp.86320 + umask 022 + cd /usr /src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 ... ... ... Recorded in: /usr/src/redhat/SRPMS/postfix- 2.2.8-1.2.src.rpm Written by: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Written by: /usr/src/redhat/RPMS/i686/postfix-pflogsumm- 2.2.8-1.2.i686.rpm Running(%clean): /bin/sh -e /var/tmp/rpm-tmp.52381 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2. 8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

We have all the package assembled, now we need to install it and enjoy life.

# rpm -ivh /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Preparing... #################### ######################### 1:postfix ######################### ###################

For a better understanding, let's look at the squid build, which has a more standard spec file structure. As always, first install src.rpm, and do not forget to check the size and checksum.

# rpm -ivh squid-2.5.STABLE11-2.src.rpm 1:squid ################################### ###########

You can find out all possible keys as follows.

# cd /usr/src/redhat/SPECS # rpmbuild --bp squid.spec # cd ../BUILD/squid-2.5.STABLE11/ # ./configure --help Usage: configure Options: Configuration: --cache-file =FILE cache test results in FILE --help print this message --no-create do not create output files --quiet, --silent do not print `checking..." messages --site-file=FILE use FILE as the site file --version print the version of autoconf that created configure Directory and file names: --prefix=PREFIX install architecture-independent files in PREFIX --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX --bindir=DIR user executables in DIR --sbindir=DIR system admin executables in DIR --libexecdir=DIR program executables in DIR --datadir=DIR read-only architecture-independent data in DIR --sysconfdir=DIR read-only single-machine data in DIR --sharedstatedir=DIR modifiable architecture-independent data in DIR --localstatedir=DIR modifiable single-machine data in DIR --libdir=DIR object code libraries in DIR --includedir=DIR C header files in DIR --oldincludedir=DIR C header files for non-gcc in DIR --infodir=DIR info documentation in DIR --mandir=DIR man documentation in DIR --srcdir=DIR find the sources in DIR --program-prefix=PREFIX prepend PREFIX to installed program names --program-suffix=SUFFIX append SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names Host type: --build=BUILD configure for building on BUILD --host=HOST configure for HOST --target=TARGET configure for TARGET Features and packages: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE --with-PACKAGE[= ARG] use PACKAGE --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --x-includes=DIR X include files are in DIR --x-libraries=DIR X library files are in DIR --enable and --with options recognized: --disable-dependency-tracking Speeds up one-time builds --enable-dependency-tracking Do not reject slow dependency extractors --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer --enable-dlmalloc[=LIB] Compile & use the malloc package by Doug Lea --enable-gnuregex Compile GNUregex. Unless you have reason to use this option, you should not enable it. This library file is usually only required on Windows and very old Unix boxes which do not have their own regex library built in. --enable-xmalloc-statistics Show malloc statistics in status page --enable-carp Enable CARP support --enable-async-io[=N_THREADS] Shorthand for --with-aufs-threads=N_THREADS --with-pthreads -- enable-storeio=ufs,aufs --with-aufs-threads=N_THREADS Tune the number of worker threads for the aufs object store. --with-pthreads Use POSIX Threads --with-aio Use POSIX AIO --with-dl Use dynamic linking --enable-storeio="list of modules" Build support for the list of store I/O modules. The default is only to build the ufs module. See src/fs for a list of available modules, or Programmers Guide section
for details on how to build your custom store module
--enable-heap-replacement
Backwards compatibility option. Please use the
new --enable-removal-policies directive instead.
--enable-removal-policies="list of policies"
Build support for the list of removal policies.
The default is only to build the lru module.
See src/repl for a list of available modules, or
Programmers Guide section 9.9 for details on how
to build your custom policy
--enable-icmp Enable ICMP pinging
--enable-delay-pools Enable delay pools to limit bandwidth usage
--enable-useragent-log Enable logging of User-Agent header
--enable-referer-log Enable logging of Referer header
--disable-wccp Disable Web Cache Coordination Protocol
--enable-kill-parent-hack
Kill parent on shutdown
--enable-snmp Enable SNMP monitoring
--enable-cachemgr-hostname[=hostname]
Make cachemgr.cgi default to this host
--enable-arp-acl Enable use of ARP ACL lists (ether address)
--enable-htcp Enable HTCP protocol
--enable-ssl Enable ssl gatewaying support using OpenSSL
--with-openssl[=prefix]
Compile with the OpenSSL libraries. The path to
the OpenSSL development libraries and headers
installation can be specified if outside of the
system standard directories
--enable-forw-via-db Enable Forw/Via database
--enable-cache-digests Use Cache Digests
see http://www.squid-cache.org/FAQ/FAQ-16.html
--enable-default-err-language=lang
Select default language for Error pages (see
errors directory)
--enable-err-languages="lang1 lang2.."
Select languages ​​to be installed. (All will be
installed by default)
--with-coss-membuf-size COSS membuf size (default 1048576 bytes)
--enable-poll Enable poll() instead of select(). Normally poll
is preferred over select, but configure knows poll
is broken on some platforms. If you think you are
smarter than the configure script, you may enable
poll with this option.
--disable-poll Disable the use of poll().
--disable-http-violations
This allows you to remove code which is known to
violate the HTTP protocol specification.
--enable-ipf-transparent
using IP-Filter network address redirection.
--enable-pf-transparent
Enable Transparent Proxy support for systems
using PF network address redirection.
--enable-linux-netfilter
Enable Transparent Proxy support for Linux 2.4.
--with-large-files Enable support for large files (logs etc).
--enable-large-cache-files
Enable support for large cache files (>2GB).
WARNING: on-disk cache format is changed by this option
--with-build-environment=model
The build environment to use. Normally one of
POSIX_V6_ILP32_OFF32 32 bits
POSIX_V6_ILP32_OFFBIG 32 bits with large file support
POSIX_V6_LP64_OFF64 64 bits
POSIX_V6_LPBIG_OFFBIG large pointers and files
XBS5_ILP32_OFF32 32 bits (legacy)
XBS5_ILP32_OFFBIG 32 bits with large file suppor
XBS5_LP64_OFF64 64 bits (legacy)
XBS5_LPBIG_OFFBIG large pointers and files
default The default for your OS
--enable-leakfinder
Enable Leak Finding code. Enabling this alone
does nothing; you also have to modify the source
code to use the leak finding functions. Probably
Useful for hackers only.
--disable-ident-lookups
This allows you to remove code that performs
Ident (RFC 931) lookups.
--disable-internal-dns This prevents Squid from directly sending and
receiving DNS messages, and instead enables the
old external "dnsserver" processes.
--enable-truncate This uses truncate() instead of unlink() when
removing cache files. Truncate gives a little
performance improvement, but may cause problems
when used with async I/O. Truncate uses more
filesystem inodes than unlink..
--disable-hostname-checks
Squid by default rejects any host names with
odd characters in their name to conform with
internet standards. If you disagree with this
you may use this switch to turn off any such
checks, provided that the resolver used by
Squid does not reject such host names.. This
may be required to participate in testbeds for
international domain names.
--enable-underscores Squid by default rejects any host names with _
in their name to conform with internet standards.
If you disagree with this you may allow _ in
hostnames by using this switch, provided that
the resolver library on the host where Squid runs
does not reject _ in hostnames...
--enable-auth="list of auth scheme modules"
Build support for the list of authentication schemes.
The default is to build support for the Basic scheme.
See src/auth for a list of available modules, or
Programmers Guide section authentication schemes
for details on how to build your custom auth scheme
module
--enable-auth-modules="list of helpers"
Backwards compatibility alias for
--enable-basic-auth-helpers
--enable-basic-auth-helpers="list of helpers"
This option selects which basic scheme proxy_auth
helpers to build and install as part of the normal
build process. For a list of available
helpers see the helpers/basic_auth directory.
--enable-ntlm-auth-helpers="list of helpers"
This option selects which proxy_auth ntlm helpers
to build and install as part of the normal build
process. For a list of available helpers see
the helpers/ntlm_auth directory.
--enable-digest-auth-helpers="list of helpers"
This option selects which digest scheme authentication
helpers to build and install as part of the normal build
helpers/digest_auth directory.
--enable-ntlm-fail-open Enable NTLM fail open, where a helper that fails
one of the Authentication steps can allow squid to
still authenticate the user.
--enable-external-acl-helpers="list of helpers"
This option selects which external_acl helpers to
build and install as part of the normal build
process. For a list of available helpers see the
helpers/external_acl directory.
--with-samba-sources=/path/to/samba-source-tree
Path where the correct Samba source files can be
found while building winbind helpers. (defaults to
use internal copies of the headers from Samba-2.2.7)

Disable-unlinkd Do not use unlinkd
--enable-stacktraces Enable automatic call backtrace on fatal errors
--enable-x-accelerator-vary
Enable support for the X-Accelerator-Vary
HTTP header. Can be used to indicate
variance within an accelerator setup.
Typically used together with other code
that adds custom HTTP headers to the requests.
--with-maxfd=N Override maximum number of filedescriptors. Useful
if you build as another user who is not privileged
to use the number of filedescriptors you want the
resulting binary to support

After you have found the required key, add it to %configure. For example, we want to build squid with ssl support. From the help, we determined that for this, we need to add two keys --enable-ssl and --with-openssl. We make the appropriate changes

Save the file and start building.

# rpmbuild -ba --target=athlon squid.spec Platforms to build: athlon Build for the athlon platform Running (%prep): /bin/sh -e /var/tmp/rpm-tmp.59199 + umask 022 + cd /usr /src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf squid-2.5.STABLE11 + /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/squid-2.5.STABLE11.tar .bz2 ... ... ... SSL gatewaying using OpenSSL enabled
Using OpenSSL MD5 implementation ... ... ... Recorded by: /usr/src/redhat/SRPMS/squid-2.5.STABLE11-2.src.rpm Recorded by: /usr/src/redhat/RPMS/athlon/squid-2.5.STABLE11- 2.athlon.rpm Running(%clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat/BUILD + cd squid-2.5.STABLE11 + rm - rf /var/tmp/squid-2.5.STABLE11-root + exit 0 Execute(--clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat /BUILD + rm -rf squid-2.5.STABLE11 + exit 0

We have assembled all squid successfully, now all that remains is to install or update it.

There are two cars, identical SLES version/arch.

Installed on computer #A software"foo" which we can see with rpm -qa .

Machine #B needs to install the software "foo".

foo.rpm is not accessible from any source, internet, etc.

Question

Since the foo.rpm package was installed on machine #A, can we create a foo.rpm file on it from the already installed files?

I think there are also pre/post scripts in rpm. So you can install foo.rpm ( with dependencies?).

2 Solutions collect form web for “How to create an RPM package from installed files?”

It's possible, but it's very difficult to get it done right. If you're desperate, you can create new file RPM .spec and create a "fake" source RPM file (SRPM), which can then be used to create the resulting RPM file using rpmbuild --rebuild .

I would continue searching for the actual RPM. You don't specify what in your question, but my experience is that you can find anything online if you know how to look for it. I found ancient versions of RPM for distributions Red Hat, which have not been used for over 10 years, so I would have a hard time believing that there is no residue in this RPM.

You can also frequently go back to the application source that is contained in the RPM and use it to restore the RPM. Often the source applications will contain a necessary .spec file which is used to restore the RPM.

Finally, you can get the source and .spec file from a build service, such as for Koji-based distributions for Red Hat. SuSE supports similar build services, so you can search for them to get old build artifacts.

Taking binary files as

You can use this method to raise actual executable files from one system and offload them for deployment on another system.

car A

$ rpm -ql | xargs tar -zcvf /tmp/program.tgz

car B

$ tar -zxvf /path/to/your/program.tgz

RPM version from SLES

According to one of the posts in this thread: Re: How to create an RPM fron installed rpm packages on SLES are supposed to have a --repackage switch. This does not exist in the Red Hat version (on Fedora or CentOS). But according to the post, you can use it like this:

$ rpm -e --repackage

After that you will find your RPM here:

/var/spool/repackage

Using rpmerizor

Rpmerizor is a third party tool/script that you can install that will repackage the source files into the appropriate RPM. Using this script is available here, under the name: rpmerizor man page.

excerpt

Rpmerizor is a script that allows you to create an RPM package from installed files. You just need to specify the files on the command line and answer a few interactive questions to fill out the rpm metadata (package name, version...). You can also use it in batch mode with options command line for metadata.

Using rpmrebuild

Not to be confused with the build tool rpmbuild, rpmrebuild is another third-party script that you can use to repackage an already installed RPM.

excerpt

rpmrebuild is a tool to create an RPM file from a package that has already been installed in basic use, using rpmrebuild does not require any knowledge about creating an rpm. (On Debian the equivalent product is dpkg-repack).

example

Let's say we want to repackage the openssh server.

$ rpm -aq | grep openssh-server openssh-server-6.2p2-8.fc19.x86_64

Now the package:

$ rpmrebuild openssh-server-6.2p2-8.fc19.x86_64 /usr/lib/rpmrebuild/rpmrebuild.sh: WARNING: some files have been modified: ..?...... c /etc/ssh/sshd_config . .?...... c /etc/sysconfig/sshd Do you want to continue ? (y/N) y Do you want to change release number? (y/N) n result: /root/rpmbuild/RPMS/x86_64/openssh-server-6.2p2-8.fc19.x86_64.rpm

• Re: How to create RPM-installed packages

As a rule, no.

With a little rpm -qi and rpm -q --changelog give an idea of ​​where the package came from.

If it was built on the system it runs on, you can still use the spec file used to generate the actual revs, if not both.

rpm -q --list Shows all files that the package deploys.

rpm -q --scripts To show any scripts that are executed when installing (or uninstalling) a package may provide as little information as possible about its purpose as the files that are deployed.

And any dependencies that need to be installed can be found using rpm -q --requires

All the manuals I found on the Internet in most cases come down to two types:
— translation of documentation (which I still advise you to read, as my article will cover only part of the information that you will need in the future)
— brief instructions, how to run rpmbuild when we already have everything.
Personally, I was faced with the need to build a package from a source, with which there was nothing, and most importantly, a spec file from which to build the package. As a result, we will write our own spec file to build the package and immediately add our own configs there (this issue is also not very well covered).

I will be building a package from the ffmpeg sources for AirVideoServer, which I already described as . I am a supporter of installing applications through it in a distribution that uses a package manager, which is why on CentOS I don’t like building software from source. For this reason, I decided to collect everything in bags for myself. Assembling the also necessary lame (it comes with spec files included) and x264 (you can write a spec file for it yourself after reading this article) should not cause you problems in the future.

And so, first we need to set up the “environment” in which we will collect the package. It is not recommended to build packages from under root, so we will create a separate user, but for now we will install all the necessary software:

Yum install gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools

Now let’s create a special user

Useradd rpmbuild

and let's go under it

Su - rpmbuild

let's execute the command

Rpmdev-setuptree

so that it would deploy the necessary directory structure for us to build
And now we can proceed directly to the assembly.
We need the source itself

Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2

unfold it

Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2

Let's put the configuration file with the contents next to it:

Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg password = subtitles.encoding = utf-8 subtitles.font = Verdana folders = Movies:/home/share/films

Let's download the server file here:

Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar

And the init script:

Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #description: AirVideo server # Source function library. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo case "$1" in start) echo -n "Starting AirVideo server: " daemon java -jar $(PREFIX_DIR)/AirVideoServerLinux.jar $( PREFIX_DIR)/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && success || failure echo ;; stop) echo -n "Stopping AirVideo server: " killproc java echo ;; status) status java ;; restart | reload) $0 stop ; $0 start ;; *) echo "Usage: airvideo (start|stop|status|reload|restart" exit 1 ;; esac

Now we can move on to writing our spec file for the assembly.
First we have the various headings. The package name, version and release are important; they will determine which directory the source will be deployed into before assembly. In Source1, Source2 and Source3 we indicate our 3 additional files, config, server and init script, which must be added to the package when building.

Name: ffmpeg Version: 2.4.5 Release: beta7 Summary: ffmpeg for AirVideoServer License: GPL URL: http://inmethod.com/airvideo/ Source: http://inmethod.com/airvideo/download/ffmpeg-for-2.4 .5-beta7.tar.bz2 Source1: airvideoserver.conf Source2: AirVideoServer Source3: AirVideoServerLinux.jar BuildRoot: %(_tmppath)/%(name)-for-%(version)-%(release)

%description Utility and library for encoding H264/AVC video streams for AirVideoServer.

The %prep section is responsible for the commands necessary to start the build, so that I don’t have to worry about renaming the directory for the format - I just use the -n switch to indicate where the unpacked sources are located

%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/

The %build section is responsible for directly assembling the source; you can change the keys to the ones you need, as with normal assembly and installation from sources:

%build ./configure \ --prefix="%(_prefix)" \ --bindir="%(_bindir)" \ --libdir="%(_libdir)" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame

The %install section contains commands for installing package files on the system; here we need to additionally specify where to install our config file, server and init script

%install %(__rm) -rf %(buildroot) %(__make) install DESTDIR="%(buildroot)" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE1) $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE2) $RPM_BUILD_ROOT/etc/init.d install -m 644 %(SOURCE3) $RPM_BUILD_ROOT/usr/local/AirVideo/

Let's clean up the garbage and run ldconfig

%clean %(__rm) -rf %(buildroot) %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

The commands in the %files section specify lists of files and directories that, with the appropriate attributes, should be copied from the build tree into the rpm package and will then be copied to the target system when this package is installed.

%files %defattr(-,root,root,-) %doc COPYING* CREDITS README* %(_bindir)/avconv %(_bindir)/avprobe %(_bindir)/avserver %(_bindir)/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar

The %doc macro marks documentation files, copyrights and other things.
With this our spec file is ready, now we need to run the assembly itself

Rpmbuild -bb ffmpeg/ffmpeg.spec

Upon successful assembly of the package, after completion, in the RPMS/_architecture_/ directory we will have our package ffmpeg-2.4.5-beta7.x86_64.rpm which can now be uploaded and deployed on any machine.

I hope this small manual will help you assemble your own packages for installation, with your own configuration files, which will make your life easier later.

First, let's figure out what should be on the system to build an rpm package. The rpm-build package must be installed. Without it, the rpmbuild command will not be available. Along with it, a number of packages used during assembly will be supplied as dependencies. In dependencies for building a package in ROSE, it is usually not customary to specify a C/C++ compiler; for this reason, sooner or later you will need the gcc and gcc-c++ packages. All other dependencies must be requested by the package itself. Of course, there are mistakes, and during the assembly process you realize that you missed something, but this is usually quite rare and not critical.

What exactly is an RPM package? RPM packages are divided into source packages - src.rpm and ready-to-install packages - %(arch).rpm. The src.rpm packages contain the original tarball (program source), any other sources, parts, and the most important spec file that controls the build process. All these files are packed into a cpio archive. When you try to enter the src.rpm package using file manager mc, you will see it. The package also contains some files with information.

%(arch).rpm packages contain a cpio archive with files that, after installation, will be distributed in the appropriate directories, information files and installation scripts.

You can also meet without source code. They are usually created for proprietary programs that cannot be included in the distribution (there are no source codes, and the binary somehow needs to be remade or is simply prohibited from being placed on distribution mirrors by the license). Inside this package there is usually only a spec file, and the binary is downloaded and, if necessary, modified during the installation of the package (for example, in a post-script, which will be discussed below).

Packages can be collected from any user. It is not recommended to do this as root, because there is a possibility that the root for the installation section will be the directory / and then the rm -rf %(buildroot) command will destroy everything in the world. It also happens that “crooked” packages are not perform the installation correctly, and place it not in a temporary directory, but directly somewhere in %(_prefix) (/usr) Some of the files will be lost, although this, of course, will not affect the performance of the package on this machine.

What needs to be done to be able to collect packages from regular user? First of all, you need to create a rpmbuild directory file in your home directory with the following structure:

~/rpmbuild |-- BUILD |-- BUILDROOT |-- RPMS | |-- i586 | |-- x86_64 | `-- noarch |-- SOURCES |-- SPECS `-- SRPMS

You need to create the BUILD , RPMS , SOURCES , SPECS , SRPMS directories manually, the RPMS directory subdirectories should be created automatically during build depending on the architecture.

In ROSE it is not customary to write the package builder and vendor in spec files; these values ​​are set automatically by the ABF build system. ABF also automatically signs compiled packages with the key of the corresponding repository. Therefore, we will not touch on these issues here.

Now let's see what the most important file of the rpm package, the spec file, is. For example, let's take it from the stardict package. This package is well suited for learning, since it contains several tarballs (program source packaged in tar), several packages are obtained, and there is such a thing as diagrams. Typically the spec file has the same name as the package itself (stardict.spec). However, you can add a package version (stardict-2.spec), useful if you are trying to support multiple branches of programs. You can even give it some other name, but this is, to put it mildly, inconvenient.

So, the contents of the stardict.spec file are given below. We will immediately insert comments after certain sections, but if you combine all the blocks into the same file, you will get a full-fledged stardict.spec.

The spec file consists of sections and a header:

Summary: StarDict dictionary Name: stardict Version: 2.4.8 Release: 4 License: GPL URL: Group: User Interface/Desktops Source0: %(name)-%(version).tar.bz2 Source1: %(name)-tools- %(version).tar.bz2 Patch0: %(name)-2.4.8-desktop.patch

Summary- a brief description of the package, Name- Name, Version- version, Release- release. The last three tags correspond to the macro definitions %(name) , %(version) , %(release) . They are often used later. Name And Version usually the same as the name of the tarball. If they differ, then in principle there is nothing to worry about, but in some places in the spec file you will have to use non-standard methods. If you are assembling a package from cvs, svn, etc., then it is recommended to make the macro definition %define date 20070422 at the very beginning of the file (in this format, you can guess why) and Release tag define as follows:

Release: 0.git%(date).4

Source*- source texts, tarballs, just files. In this example there are two tarballs with different programs, which makes assembly much more difficult. Regular files, such as configurations, can simply be copied to the %%install section using the install command. It has a simple syntax, install -m mask_as_chmod what goes where. You can also create directories using it. It is not used in our example, but you can read more about it in man.

Patch- patches, fixes that you or someone else have released for this package. It is not customary to change the source code of the program itself and then wrap it in a tarball. It is customary to apply patches. You can do them as follows. Unpack the original tarball, for us it will be stardict-2.4.8, then copy stardict-2.4.8 to stardict-2.4.8.orig. After that, change the code in the stardict-2.4.8 directory, exit it and issue the command diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-patch_name.patch. As you can see, before the patch is added there is %(name)-%(version) of the package. In the spec file itself, you must write the name of the patch without macro definitions. At least a version, for sure. Otherwise, when you update the package version, you will update the version of the patch defined by the %(version) macro, and the patch may be suitable for new version program without any changes. If during the assembly itself the patch could not be applied, then it should either be remade for this version program, or disable it in the %setup section.

In the spec files of packages of many distributions, you can also find in the header a definition of BuildRoot - the directory in which the build is carried out. In ROSE this definition is not necessary; the name BuildRoot is generated automatically.

BuildRequires: libgnomeui-devel >= 2.2.0 BuildRequires: scrollkeeper BuildRequires: gettext Requires(post): GConf2 Requires(post): scrollkeeper Requires(postun): scrollkeeper

BuildRequires is a section in which packages that are required to build our program are written, separated by commas or separated by spaces. You can get them from some README and INSTALL files (although there is rarely anything useful about this), from the configuration process (on this moment usually this is a configure script) and from the build process itself (sometimes configure will miss something and the build will stop).

Requires - this section contains packages or files(!) that this package will require during installation. When building, the dependencies will automatically include all the libraries that our package will require, but you can also specify the packages manually. Rpm also automatically registers the dependencies of perl, python, mono and some others (all these dependencies are written not in the spec file, of course, but in the package itself). If you do not need dependencies to be registered automatically, you should add a new AutoReq: no tag to the spec file. It is usually prescribed when building proprietary programs, since rpm adds internal dependencies from the compiled program.

Our example uses the Requires(post) and Requires(postun) constructs for dependencies in the install and uninstall scripts. In principle, a simple Requires is sufficient. There's not much to comment on here. It’s just that StarDict itself doesn’t need these dependencies during operation. They are needed only during installation and removal.

There are several other useful tags that are not used here.

Provides: title1, title2

Names other than %(name) that this package will respond to. It is convenient to indicate if you have changed the name of a package, but other packages continue to depend on the old name.

Obsoletes: name1, name2

Removes the specified packages when installing the current package. It is as if they were saying that this package replaces the ones specified (in terms of functionality, set of files, etc.). You can use the construction name< . Тут вы должны сами понимать, что к чему.

Conflicts: title1, title2

Packages that conflict with the current one are listed. It is implied that these packages must be manually removed before installing ours. Constructions with comparison marks and versions are also used (see above).

Suggests: title1, title2

- soft dependencies are packages that add additional functionality to a given package (for example, codecs for a media player), but which you can do without.

Epoch: number

Usually it is either not indicated at all or equal to 0. The essence of this parameter is this. Let our package stardict still have the version 2.4.8 and there is also an older one 2.4.5 . So if stardict 2.4.5 has %(epoch) 1 , and for 2.4.8 - 0 , then package 2.4.5 will always be newer than 2.4.8. This is what RPM will tell you during installation. This parameter is convenient if you want to roll back to a previous version (of course, if you put everything in a public repository and grab everything through urpmi or rpmdrake . For “home” needs, the parameter rpm --force is suitable). If the Epoch: 0 tag is defined, then the packet will take precedence over a packet with an undefined Epoch tag.

BuildArch: architecture

The architecture under which our package will be assembled. If this option is not specified, the package will be built for the current architecture. Typically this option is specified in order to build an architecture package noarch, that is, a package that does not contain binaries.

ExclusiveArch: architecture1 architecture2

Architectures for which this package can be assembled. Typically used when assembling modules for the kernel.

This is where the header ends and the individual sections begin.

%description StarDict is an international dictionary written for the GNOME environment. It has powerful features such as "Glob-style pattern matching," "Scan selection word," "Fuzzy search," etc.

Description of the main package, the one with the name %(name)

%package tools Summary: StarDict-Editor Requires: %(name) = %(version)-%(release) Group: User Interface/Desktops

Here we create a new package whose name will be %(name)-tools . If you need to call the package something completely different, you should do it, for example, like this: %package -n tools-stardict . The version of the new package is taken from the given Version tag. Pay attention to Requires. It contains a dependency on the main stardict package. If it had %(epoch) , then it would be necessary to specify Requires: %(name)-%(epoch):%(version)-%(release). Otherwise, you simply will not be able to install this package.

%description tools A simple tool for StarDict.

Description of the second package

%prep %setup -q -a1 %patch0 -p1

The %prep section begins preparation for assembly. %setup unpacks the sources. Option -q does not show archive unpacking output. Option -a1 used to unpack %(SOURCE1) , the second tarball inside(!) the directory of the first tarball. Accordingly, the number indicates the SOURCE number. The parameter is also sometimes used -b, then the second tarball is unpacked into the same directory as the first. Accordingly, if we have one tarball, then the options -a, -b are not used.

If your first directory in the tarball has a name different from %(name)-%(version), then rpm will not be able to automatically enter this directory. In this case, you should change %setup a little. If in the archive stardict-2.4.8.tar.bz2 the first directory is named, for example, simply stardict , then it will look like this:

%setup -q -n %(name) -a1

Immediately after unpacking the package, before %patch , if necessary, you can copy the files, or run any programs to change the sources. Let's say copy the Russification file, or correct some source code with sed. Just call cp, sed or something else here. The root here is the directory into which the first tarball was unpacked (the $RPM_BUILD_DIR variable is responsible for it, but it is extremely rarely used).

Using %patch patches are applied. If you made a patch, as we wrote above, then you will always have the parameter -p1. The parameter is also often used -b .patch_name, to create a backup.

%build pushd %(name)-tools-%(version) %configure %make popd %configure %make

The %build section is where the package is built. Pay attention to pushd and popd. With these commands we navigate and exit the second tarball directory. This will be the root directory after pushd . After the popd command we will return to the directory of the first tarball. Accordingly, if you have one source, then you do not need to use these commands.

Since we have two programs in one package, we run %configure configuration twice and make twice. If the package is configured using autotools , then the %configure macro runs the configure script from the root of the unpacked tarball. It usually has many parameters, they can be viewed from the command line using ./configure --help . After %configure you can specify the parameters you need. Note that the call to %configure and ./configure are different. In the first case, the correct directories for installation (as well as standard parameters) will be transferred to the configurator, in the second - default directories.

After a successful configuration, assembly occurs, namely the %make macro, which calls the command of the same name with some additional parameters (in particular, on multiprocessor machines, parallel assembly is used - the option -j).

If the package does not use autotools, then %configure and maybe %make do not need to be used; to build, read the README and INSTALL file. ROSA also has macros for other situations - for example, %cmake for the build tool of the same name.

When the build is completed successfully, the %install section comes into effect.

%install pushd %(name)-tools-%(version) %makeinstall_std popd %makeinstall_std %find_lang %(name)

%%find_lang , search for localization files. Its parameter is the name of the files that will be located in the directory after installation %(buildroot)/usr/share/locale/*/LC_MESSAGES/*.mo. This usually matches %(name) . If this is not the case, write a different name.

In many spec files, you may notice that the command rm -rf %(buildroot) or rm -rf $RPM_BUILD_ROOT is executed at the very beginning of the %install section, as well as the %clean section with the same lines. In modern ROSE there is no need for this; such cleaning is performed automatically.

%preun %preun_uninstall_gconf_schemas %(name)

Sections for installation scripts. In general, there are several of them. %pre - executed before installation, %post - after installation, %preun - before removal, %postun - after removal. In our example, uninstalling removes the Gconf schemas. Here we assume that there is only one schema in the package and its name is the same as the package name. Please note that to remove schemas we call a special macro; this macro is expanded by ROSA's rpmbuild into a set of necessary Shell commands, which, in fact, delete the schema. Installation of schemas when installing a package is performed automatically using RPM file triggers.

Each package may have its own scripts, so you should also read the documentation. If no scripts are needed for proper operation, then these sections should not be used. You can use bash scripts in these sections (just like in any other sections).

In the %files sections we must specify which files should be packaged. All files must be specified, otherwise rpmbuild will report unpacked files.

Option -f a file containing a list of processed files is specified. In our case, this file contains the paths to the localization files. You can, in principle, create your own file and insert it.

Special macro definitions are used to define directories.

• %(_prefix) - /usr
• %(_sysconfdir) - /etc
• %(_bindir) - /usr/bin
• %(_datadir) - /usr/share
• %(_libdir) - /usr/lib or /usr/lib64 depending on the system bit depth
• %(_lib) - /lib or /lib64, respectively
• %(_libexecdir) - /usr/libexec
• %(_includedir) - /usr/unclude
• %(_mandir) - /usr/share/man
• %(_sbindir) - /usr/sbin
• %(_localstatedir) - /var .
• %(systemd_libdir) - /usr/lib/systemd

%doc marks files as documentation. The third line copies specified files to the catalog %(_datadir)/doc/%(name)-%(version). By default, files in the rpm package will be owned by root, and root access rights will be the same as during the installation process. If this needs to be changed, then use the %defattr construct.

%files tools %(_bindir)/stardict-editor

Same for the stardict-tools package. If it were called tools-stardict , then %files would look like this:

%files -n tools-%(name).

The last thing in the spec file is %changelog . In the changelog you indicate the changes in the package compared to previous version. Its syntax is approximately as follows.

%changelog * Sun Apr 22 2007 Your Name - 2.4.8-4 - update desktop patch

Macro definitions

Now it's time to take a closer look at macros and variables. Let's say we are building a package from SVN, in in this case The release usually includes the revision date. At the very beginning of the spec file you need to define the date variable:

%define date 20070612

As we can see, the macro definition %define is responsible for defining variables. Now, anywhere in the spec file, we can use our variable in the form %(date) (the parentheses are not required, but in ROSE it is customary to put variables in brackets, and not to take macro definitions; it’s easier to distinguish them this way). For example, defining the main parameters would look something like this:

Version: 0.5 Release: 0.svn%(date).3

Please note that the date is preceded by 0. , and after the date - a number, which increases if necessary to raise the release. Why is this done? When will the final version finally be released (in our case - 0.5 ), the revision can be removed and simply written into the release 1 . At the same time, literal 1 greater than any line starting with 0 , and the package will be considered newer than pre-release packages built from SVN revisions.

An extremely popular macro definition is the construction

%if condition action1 %else action2 %endif

or just %if without %else . The idea is simple, if the condition at %if is true, then action1 is executed, otherwise action2 is executed.

Let's say we are again collecting something from SVN. Usually inside the archive, if it is from SVN, instead of the %(name)-%(version) directory, they simply indicate %(name) (the sim-0.9.5.tar.bz2 archive has a sim directory inside, since the final release is sim 0.9.5 does not exist. The final release will have sim-0.9.5 as its first directory). To avoid rewriting the spec file every time, you can make the following macro definitions:

%define svn 1 ... %prep %if %(svn) %setup -q -n %(name) %else %setup -q %endif

If the svn variable is not defined, then the part of the script after %else will be executed. You can also use a stricter condition (don't forget the quotes):

%define svn 1 ... %prep %if "%(svn)" == "1" %setup -q -n %(name) %else %setup -q %endif

Inside all sections of the spec file, we can use any Linux commands, without any bells and whistles, but in the file header it’s not so simple. For example, we need to define firefox version for the package (let's say epiphany) and add it to the Requires: section. It will look like this:

Requires: firefox = %(rpm -q firefox --qf "%%(version)")

Please note that the external command is executed in %() (almost like bash - $() ) and in the spec file you must put two % signs in the parameters. This way you can call any Linux commands, for example, to determine the kernel version.

Another popular macro definition is the %ifarch .. %endif construct. If the architecture matches the one specified after %ifarch , then some action is performed. The architectures come in i386, i486, i586, i686, i?86, x86_64, and, of course, some others that you probably won’t come across.

As noted above, in all sections of the spec file you can use any Shell commands, including for, while, if, etc.

Building the package

Now let's move on directly to assembling the package. Sources and patches should be in the SOURCES directory, and the spec file should be in the SPECS directory. After this you need to issue the command:

Rpmbuild -ba spec file

After this, the package will be built (or not built, but will fall out with errors), and binary packages will appear in the subdirectories of the RPMS directory, and the source will appear in the SRPMS directory.

Very often, just before the build is completed, rpmbuild displays a message about files found but unpacked. This means that you simply did not include them in the %files section. You just need to add them there. If you do not want these files to be included in the package, you can use one of the following methods:

• Add a macro definition to the %files section

• Add a macro definition to the beginning of the spec file

If you need to build only the binary or only the source, then instead of -ba should be used -bb And -bs respectively. Among the useful parameters of rpmbuild we can note -clean(remove all garbage), -rmsource(remove sources from the SOURCE directory) and -target=architecture(build a package for a specific architecture).

You can also run scripts only in a specific section. We will not describe such parameters here, see man rpmbuild.

Building an RPM package from one already installed on the system

Sometimes a situation happens that some package is already installed on the system (maybe in a very old system) and you really want to get an rpm with it, but it just hasn’t been saved. You may also want to quickly put together a package with configuration files modified to suit your needs.

To solve this problem, you should use the rpmrebuild utility. This utility, written in bash, is available in the ROSA contrib repository.

It's extremely easy to work with. You just need to issue the command:

Rpmrebuild installed package_name

If any file has been changed, you will be notified about it, but the build process will not be interrupted.

Rpmrebuild has a huge number of parameters, for example, you can change the release of the package, changelog, scripts, Requires sections, package descriptions and much more. You can even simply change the spec file, which the script will generate itself. It's true that it will be a little scary, but it's still better than nothing.

All parameters can be viewed using

Rpmrebuild --help