Splitting the RPM

When dealing with RPMS, you sometime need to split the libraries from the other files. The reason for this is to minimize the footprint and allow the use of the libraries alone (when the application in itself is not required). You can also use this method to remove unwanted parts of an application with the option to add them when required (creating a separate plugin rpm for example). Also if development files are present, these should be separated.

In order to create separate RPMS for the libraries, devel files or other reasons, you will need to create for each one:

  • A new summary section
  • A new file section

The build section remains the same regardless of the number of subsections.

Creating library names

First we need to create the library names. So we'll start by defining the library macros.

	 
%define major 1	 
%define libname %mklibname %{name} %major	 
%define libnamedev %mklibname %{name} %major -d	 
These 3 lines is the standard pclos method for defining library names and allows for the automatic generation of the proper names (use them, they are your friends).

%major

This macro needs to be placed to allow for future incompatibility by allowing you to have 2 libraries with the same name but different major (in case of change of API) which in turn will allow old programs to use the old library while newer programs can use the new library.

%mklibname

This macro creates the library name base on the arguments behind it (%{name} %{major} -d (-d is for devel)

e_dbus Example

So if we look at the example below, the rpms created will be:

  • e_dbus-0.1.0.002-1pclos_tinyme2007.i586.rpm
  • libe_dbus1-0.1.0.002-1pclos_tinyme2007.i586.rpm
  • libe_dbus1-devel-0.1.0.002-1pclos_tinyme2007.i586.rpm

You can download the SRPM which contains this spec file at the TinyMe E17 repo section.

%define name e_dbus	 
%define version 0.1.0.002	 
%define release %mkrel 1	 
	  
%define major 1	 
%define libname %mklibname %{name} %major	 
%define libnamedev %mklibname %{name} %major -d	 
 
Summary: Basic convenience wrappers around dbus to ease integrating dbus with EFL based applications	 
Name: %{name}	 
Version: %{version}	 
Release: %{release}	 
License: BSD	 
Group: Graphical desktop/Enlightenment	 
URL: http://get-e.org/	 
Source: %{name}-%{version}.tar.gz	 
BuildRoot: %{_tmppath}/%{name}-buildroot	 
BuildRequires: ewl-devel	 
	 
%description	 
This is the start of some basic convenience wrappers around dbus to ease integrating dbus with EFL based applications.	 
	 
%package -n %libname	 
Summary: Libraries for the %{name} package	 
Group: System/Libraries	 
	 
%description -n %libname	 
Libraries for %{name}	 
	 
%package -n %libnamedev	 
Summary: Headers and development libraries from %{name}	 
Group: Development/Other	 
Requires: %libname = %{version}	 
Provides: lib%{name}-devel = %{version}-%{release}	 
Provides: %name-devel = %{version}-%{release}	 
	 
%description -n %libnamedev	 
%{name} development headers and libraries	 
	 
%prep	 
%setup -q	 
	 
%build	 
%{configure} --prefix=%{_prefix}	 
%{__make} %{?_smp_mflags} %{?mflags}	 
	 
%install	 
%{__make} %{?mflags_install} DESTDIR=$RPM_BUILD_ROOT install	 
	 
	 
%post -n %libname -p /sbin/ldconfig	 
%postun -n %libname -p /sbin/ldconfig	 
	 
%clean	 
rm -rf $RPM_BUILD_ROOT	 
	 
%files	 
%defattr(-,root,root)	 
%doc AUTHORS COPYING README	 
%{_bindir}/e_dbus*	 
	 
%files -n %libname	 
%defattr(-,root,root)	 
%{_libdir}/lib*.so.*	 
	 
%files -n %libnamedev	 
%defattr(-,root,root)	 
%{_libdir}/pkgconfig/*	 
%_libdir/lib*.so	 
%_libdir/lib*.a	 
%_libdir/lib*.la	 
%{_includedir}/*.h	 
	 
%changelog	 
* Thu Jul 12 2007 Gettinther <gettinther at gmail.com> 0.1.0.002-1pclos_tinyme	 
- Updated to version 0.1.0.002	 
	 
* Wed Jun 20 2007 Gettinther <gettinther at gmail.com> 0.1.0.001-1pclos_tinyme	 
- rebuild for pclos2007	 
Now that we have defined the names of each sub-packages we whish to build, we can build the summary sections and file sections. Each sub package must have it's own summary and file sections. They are not as complicated as the main package sections.

Summary section

%package

This specifies the name of the package being defined in this summary subsection. Typically, use -n %libname. -n tells %package to use the name %libname (which was defined earlier).

Summary

Required for each subsection. It uses the same principle as the main section.

Group

Required for each subsection. It uses the same principle as the main section. You can put additional requirements and requirements. Just add the lines BuildRequires: and Requires: like the main section.

%description

The sub-package requires a description of what it does or what it's for.

File Section

The file section is similar to the main file section except that you will need to add the subsection name after the %file. Typical use is %file -n nameofthesubsection.

Okay! In the example above, you can see how libraries, development libraries are split. All library files and development files should be split for eventual use by some other application. We are now able to make an RPM and split it to have dedicated packages. Now we'll have a look at spec files with multiple sources.

 
build-rpms/splitting.txt ยท Last modified: 2009/03/01 01:12 by kdulcimer
Recent changes RSS feed Creative Commons License Valid XHTML 1.0 Valid CSS Driven by DokuWiki