It seems that the RPM logic is quite different from what I know already and I am having some issues understanding the "RPM logic". For my work, I have to create a documentation on "How-to create a RPM package on Red Hat 5".
I'm used to Debian and it's derivatives (Ubuntu, and so on) and thus to Debian packages (aka. .deb files).
From what I read, it seems that ones need to be root to create a RPM package. While I understand why root could be required to install a package, I still don't understand why elevated privileges should be needed just to create one.
If I try to create a RPM package as a user, changing the buildroot it fails on the %installstep because I don't have permission to write files into /usr/bin. Fair enough but... why does it want to copy my files into /usr/bin at this step?! I just want to create the package, not install it!
I'm sure I'm missing something here. Is there anyone who could give me at least a basic understanding of how rpmbuild works and why?
Will this do?
You don't need to be root to build RPM packages. I recommend you to read this two part article to get you started.
The official Maximum RPM book also has a chapter on Having RPM Use a Different Build Area, which allows non-root users to build RPMs.
Related
My knowledge on Linux administration is limited and hence wanted to check here about the pros and cons of installing any RHEL/CentOS Linux software using rpm packages over installing through tar/zip files.
Thanks
a non-exhaustive list of pros and contras:
rpm
intelligent dependency managment
conflict checking
allow easy and clean uninstall
allow for upgrades / downgrades
list all files owned by a package
a central database with all packages installed, which files they own, their interdependencies
from source
you choose yourself all compiler flags
you can choose a custom installation path
I have tried to explain the diff, pros and cons,
Tar
Basically tar is old way of dealing with in Linux. We can say its existence when the Linux was created.
Usually the tar consists of Source Code and needs to be compiled in binary format for us to use.
Pros:
Using tar packages you gain more control over the programs that you install.
If you want certain portions that avoided, you could do that on the go. Which give you the upper hand.
Cons:
The main issue comes in the maintainability of the packages installed.
They are hard to manage. Once you install, there was no way to manage the software unless and until its well documented. It also hard to version them and you are left blank on the software version you have. The possible reason for this because of the non-indexing nature of files. The files could be spread across your file system, which makes it difficult to remove or upgrade it.
Hard to automate.
It is also hard to automate because of the complexities in maintaining the packages.
Below I tried explaining how tar file are compiled to get better understanding,
Prepare(setup) environment for building
./configure
This script has lots of options that you should change. Like --prefix or --with-dir=/foo. That means every system has a different configuration. Also ./configure checks for missing libraries that should be installed. Anything wrong here causes not to build your application. That's why distros have packages that are installed on different places, because every distro thinks it's better to install certain libraries and files to certain directories. It is said to run ./configure, but in fact you should change it always.
Building the system
make
This is actually make all by default. And every make has different actions to do. Some do building, some do tests after building, some do checkout from external SCM repositories. Usually you don't have to give any parameters, but again some packages execute them differently.
Install to the system
make install
This installs the package in the place specified with configure. If you want you can specify ./configure to point to your home directory. However, lots of configure options are pointing to /usr or /usr/local. That means then you have to use actually sudo make install because only root can copy files to /usr and /usr/local.
Please go through the below link for more information on the above commands
Why always ./configure; make; make install; as 3 separate steps?
RPM
The RPM Package Manager (RPM) is an open packaging system,
RPM packages pre-compiled binary packages (as well as source packages) for an easy one-click installation experience. RPM by itself does not manage dependency and resolve conflicts. When combined with Yum or PackageKit it will resolve all the dependency for the package.
RPM makes system updates easy. Installing, uninstalling and upgrading RPM packages can be accomplished with short commands. RPM maintains a database of installed packages and their files, so you can invoke powerful queries and verification on your system. During upgrades, RPM handles configuration files carefully, so that you never lose your customisation, that you cannot accomplish with regular .tar files.
RPM feature has the ability to verify packages. If you deleted an important file for some package, you can verify the package. You will notified of changes, if any—at which point you can reinstall the package, if necessary. Any configuration files that you modified are preserved during re installation.
Pros:
Install, reinstall, remove, upgrade and verify packages
Use a database of installed packages to query and verify packages
Use metadata to describe packages, their installation instructions, and so on
Package pristine software sources into source and binary packages
Add packages to Yum repositories
Digitally sign your packages
Querying a package (if the package is on your local file system or after the package is installed)
Validating a package (checking a package has not been tampered with, before or after installation).
Cons
Not as customisable as tar.
eg on usability: We will see how to install package using Tar or rpm:
in Tar:
$ tar xvf package.tar
$ cd package
$ ./configure --prefix=PREFIX
$ make
$ make install
in RPM:
rpm -U package-2.4.x-1.i686.rpm
That simple!!.
It basically depends on the usability and the purpose of your use.
Each of them has its on pros and cons depends on how and for what we use it.
I know it a long explanation,how this will give you clear picture. I know there are more untouched such as architecture and execution. I am not pretty confident to explain those here.
In simple words you can say that rpm are prepackaged binaries. They're just ready to go, it does everything for you. But to install rpm and deb you need to be root to have some write permissions. That leaves some serious security hole in the system. You may be unknowingly installing a Torjan horse. Also if the packages are screwed up they may cause the installation to fail altogether.
I personally recommend using tar as you are in more control. It is old school, I know, that's why a bit difficult but, in my opinion best way to go.
You can further refer to the link:
https://tldp.org/HOWTO/Software-Building-HOWTO-4.html
Good afternoon,
I am currently building an RPM that has some requirements I have not found answers to on the web. I have narrowed this down to a single question.
Normally when I run an install from command line, one of the steps has me run the following command yum groupinstall "Compatibility libraries" which installs 32-bit compatibility libraries on my 64-bit desktop. I am wondering if there is a way to accomplish this in the Requires: field of my RPM-spec file, as I have only found a way to require very specific RPM's for dependencies?
I could always add in the 10-15 individual packages that get installed with yum groupinstall "Compatibility Libraries", but I was hoping there was a better option.
Description of RPM:
My RPM is very basic in nature. It will untar multiple tar files into various locations, overwrite files throughout the main install directory, install compatibility libraries, and then proceed to startup a service.
If anyone needs more information to what I am trying to accomplish please let me know. Thank you.
You can only require specific packages, not groups, in your Requires: lines. You should absolutely not run yum in your %post script, because then (a) you are then hiding your dependencies, and nobody likes to see things get installed that they didn't expect, and (b) you will probably end up getting stuck because yum in %post would need to wait for the existing yum process to exit.
For library Requires:, the rpm build process will generally figure things out for you. You still need to manually specify the appropriate BuildRequires: dependencies, which are things that are required to build the package.
If you want to update your question with more details (e.g., a link to the spec file and a description of what you're trying to do, if it's not obvious from the spec), maybe we can come up with better solutions.
I'm trying to use RPMs to install public and private software into disk images that are eventually written to the boot flash of Linux based embedded systems.
My current methodology is to mount the image (/mnt/foo) read/write on a CentOS 6.5 box and use the rpm --installroot=/mnt/foo option. There are two problems:
--installroot=/mnt/foo appears to chroot into /mnt/foo, meaning that when the post install scripts run /bin/sh (etc.) they're actually using /mnt/foo/bin/sh (etc.) That's sort of workable if the target architecture is the same as the installation box but gets very messy if its not. I'm interested to hear if someone has solved this before.
At a higher level it would be nice to use yum or apt-get or ??? to handle package dependencies and repositories. yum is the obvious choice on CentOS but it has a weak grasp of non-native architectures and would likely require some hacking. apt-get looks more promising in that department but in truth I've never used it and my attempts to install it on CentOS 6.5 have left me in dependency hell.
This seems like a problem someone would have hit before but unfortunately everything I can find about RPMs and embedded systems assumes identical processor architectures.
Bottom line, I need to use RPMs to install software to a Linux image that will be the boot disk for a embedded system. Other than doing the rpm install as part of the image installation on the embedded system (our installation time is already a big problem) I'm open to just about anything.
Any suggestions will be gratefully received.
Have you tried using some continuous build system like Jenkins? You can use that to easily set up build hosts on any architecture/platform you like, so long as that platform has some basic tools (like ssh).
You could use a combination of the --installroot flag mentioned by other commenters, alongside of some VMs setup as build hosts in Jenkins in order to install your RPMs in a specific directory while avoiding any platform/architecture issues.
I'm not sure what your specific requirements are, but, depending on how far you are willing to go... RPMs are just compressed CPIO archives with a header, so you could use rpm2cpio piped to cpio to extract the files in the RPM. You can then extract the postinstall scripts using rpm -qp --scripts filename.rpm and run them yourself. The downside to this, is of course, that you lose a lot of the benefit of using RPM/yum in the first place like the automatic installation of dependencies, and so on.
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.
Is there an easy procedure to build an RPM.If so Please explain or provide the link.........
My requirement is very simple ..
I have two other RPMs which should be combined into one single RPM....
Please explain the process....
Thanks in advance..........
Building an RPM itself is rather easy, you just need to run
rpmbuild -ba <mypackage.spec>
The more complex task is creating the .spec file, which controls how the rpm itself is built. A good explanation is the book Maximum RPM, which is available on the rpm homepage. Creating a .spec file is handled here. From my own experience building a .spec file is something that's not easy -- but not too complicated either unless you want to make special things. The standard ./configure && make && make install is usually not too complicated.
Not sure what the problem is; if you've already got two RPMs, why do you need to make them into 1 rpm? Why not just use a shell script to install them both at the same time?
The RPM command will take multiple arguments, so for example:
rpm -ivh one.rpm two.rpm three.rpm
Will install one, followed by two, followed by three.
Otherwise, from what I know, you're going to have to build the packages first, and then build them into an RPM, at which point you will have a custom RPM that will have to be manually updated every time one of the component packages changes. Yuck.
Basic guide for RPM creation is available at:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package
A very good and complete guide for RPM creation (by Fedora community) is available at link: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
It is is wonderful.
BTW, for straight answer of your question, you might want to add two packages as a subpackage of another package. For that there are some specific entries in RPM spec file.
You need to create only one SPEC file for all three packages