18.4. Spec File Changes For Subpackages

Later in the spec file, there is a %package directive:

%package bar
            

This would result in the name of the subpackage being foo-bar.

In this way, it's easy to see the relationship of the subpackage to the main package (or other subpackages, for that matter). Of course, this naming convention might not be appropriate in every case. So there is an option to the %package directive for just this circumstance.

The result is that the subpackage name would then be bar instead of foo-bar.

Since our package name is foo, and since the %package directive creates subpackage names by prepending the package name, the %package directives for the foo-server and foo-client subpackages would be written as:

%package server
%package client
            

Since the baz library's package name is not to start with foo, we need to use the -n option on its %package directive:

%package -n bazlib
            

Our requirements further state that foo-server and foo-client are to have the same version as the main package.

One of the time-saving aspects of using subpackages is that there is no need to duplicate information for each subpackage if it is already defined in the main package. Therefore, since the main package's preamble has a version tag defining the version as 2.7, the two subpackages that lack a version tag in their preambles will simply inherit the main package's version definition.

Since the bazlib subpackage's preamble contains a version tag, it must have its own unique version.

In addition, each subpackage must have its own summary tag.

So based on these requirements, our spec file now looks like this:

Name: foo
Version: 2.7
Release: 1
Source: foo-2.7.tgz
CopyRight: probably not
Summary: The foo app, and the baz library needed to build it
Group: bogus/junque
%description
This is the long description of the foo app, and the baz library needed to
build it...

%package server
Summary: The foo server

%package client
Summary: The foo client

%package -n bazlib
Version: 5.6
Summary: The baz library
            

We can see the subpackage structure starting to appear now.

Our spec file is incomplete. The bottom line is that each subpackage must have these three tags:

1. The %description tag.

2. The group tag.

3. The summary tag.

It's easy to see that the first two tags are required, but what about summary? Well, we lucked out on that one: we already included a summary for each subpackage in our example spec file.

Let's take a look at the %description tag first.

our %description tags would start with:

%description server
%description client
%description -n bazlib
            

Notice that we've included the -n option in the %description tag for bazlib. This was intentional, as it makes the name completely unambiguous.

Let's take a look at what we've done. We've created a main preamble as we normally would. We then created three additional preambles, each starting with a %package directive. Finally, we added a few tags to the subpackage preambles.

But what about version tags? Aren't the server and client subpackages missing them?

Not really. Remember that if a subpackage is missing a given tag, it will inherit the value of that tag from the main preamble. We're well on our way to having a complete spec file, but we aren't quite there yet.

Let's continue by looking at the next part of the spec file that changes when building subpackages.

As you can see we've added %files lists for:

• The main foo package.

• The foo-server subpackage.

• The foo-client subpackage.

• The bazlib subpackage.

As pre-install scripts go, these don't do very much. But they will allow us to see how subpackage-specific scripts can be defined.

Those of you that have built packages before probably realize that our spec file is missing something. Let's add that part now.