Re: Single RPM from multiple applications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In regard to: Single RPM from multiple applications, Matt Pounsett said (at...:

>Now, I realize that the easy and obvious way to manage this is to have one
>spec file each for Bar and Baz, which each have two %package sections for the
>-client and -server halves, and appropriately set co-requisites -- four RPMs
>in total.  However, I'd like to have a single spec file, which takes the
>Bar-1.3.tar.gz and Baz-1.0.tar.gz source files, does the configure and build
>for both, and creates only two RPMs -- Foo-plugins-client and
>Foo-plugins-server.  This gives me fewer spec files to maintain, and fewer
>RPMs to move around when setting up new machines.

Assuming that both Bar and Baz are relatively easy to build, going the
combined specfile is certainly possible.

If the build process is long, convoluted, or otherwise takes a lot of
space in your spec file, then combining the two into one spec can lead to
a spec that is huge, confusing, and hard to work with.

An example (perhaps mainly an example of long, convoluted, and hard to
follow ;-) ) is the RedHat 9 or RedHat ES 3 `openldap.spec' spec file.  It
includes custom versions of automake, libtool, and berkeley DB, all of
which get built *just* so that you can get to the process of building
openldap.

>Is this at all possible?

:-) All things are possible with RPM, if you're determined.

>  If so, can anyone point me to some docs that explain
>how to build the spec file appropriately, or even just an example SRPM I can
>look at to see how this functions?

I would set some defines at the top of the spec file:

# The tarball base name is this:
%define	FOO_SOURCE_FILE		Foo
# It untars into a directory with this as the name (n
%define	FOO_SOURCE_DIR		foo
%define	FOO_VERSION			1.9

# Bar is consistent, the tarball name and the directory that it untars
# into are named the same.
%define	BAR_SOURCE_FILE		Bar
%define	BAR_SOURCE_DIR		%{BAR_SOURCE_FILE}
%define	BAR_VERSION			1.3

# Baz is not consistent, the tarball is baz-source-1.0.tar.gz, but the
# tarball untars into baz-1.0
%define	BAZ_SOURCE_FILE		baz-source
%define	BAZ_SOURCE_DIR		baz
%define	BAZ_VERSION			1.0

If all of Foo, Bar, and Baz maintain a *consistent* naming scheme (the
tarball is named <Name>-<version>.tar.gz, with the first letter of Name
capitalized *and* when you untar it it goes into the directory
<Name>-<version>, also with the first letter capitalized) then you can do
away with the XXX_SOURCE_FILE and XXX_SOURCE_DIR defines, I just use them
sometimes to "abstract" what the tarball name is and also what the
untarred directory name is, for packages that have multiple sources
without a consistent scheme.

Then in the "header" area you list your sources:

Source0: /path/or/url/to/%{FOO_SOURCE_FILE}-%{FOO_VERSION}.tar.gz
Source1: /path/or/url/to/%{BAR_SOURCE_FILE}-%{BAR_VERSION}.tar.gz
Source2: /path/or/url/to/%{BAZ_SOURCE_FILE}-%{BAZ_VERSION}.tar.gz


Next, in %prep you'll probably need

%setup -c -n Foo-megapackage -a 1 -a 2

By doing that, in your build directory you'll end up with

    Foo-megapackage/
                    foo-1.9/
                    Bar-1.3/
                    baz-source-1.0/

and at the start of every spec file section (%build, %install, %clean)
you'll be dropped into the `Foo-megapackage' directory.

In the %build section, you'll need to cd into the three directories, do
the builds, and then cd up and down into the next directory.  For example:

%build

cd %{FOO_SOURCE_DIR}-%{VERSION}
	# do your build stuff...
cd ../%{BAR_SOURCE_DIR}-%{VERSION}
	# do your build stuff...
cd ../%{BAZ_SOURCE_DIR}-%{VERSION}
	# do your build stuff....


The same thing likely needs to be done in the %install section.  Note
that I've seen Red Hat spec files rely on bash being the script
interpreter, using `pushd' and `popd' to move around directories.

Once you've gotten this far, the %files section is easy.  You just need
to decide what subpackage owns which files, and it sounds like you've
already decided that.

Hope this helps,

Tim
-- 
Tim Mooney                              mooney@xxxxxxxxxxxxxxxxxxxxxxxxx
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux