Table of ContentsSplitting the RPMWhen 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:
The build section remains the same regardless of the number of subsections. Creating library namesFirst 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).
%majorThis 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. %mklibnameThis macro creates the library name base on the arguments behind it (%{name} %{major} -d (-d is for devel) e_dbus ExampleSo if we look at the example below, the rpms created will be:
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%packageThis 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). SummaryRequired for each subsection. It uses the same principle as the main section. GroupRequired 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. %descriptionThe sub-package requires a description of what it does or what it's for. File SectionThe 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. |