.spec file notes

.Spec file Notes

1. This is a revision of:
2. http://www.e-smith.org/docs/howto/building-contribs-example.spec
3. This is an example spec file for SME Server rpm building.
4. The Summary line is a single line description of the module.

Summary: PackageName for SME Server

1. anything starting with a % sign is a command that is interpreted by
2. the RPM program. Using % commands we can set values and use them
3. again later.

1. here we define a base name for the module, which will get used in
2. various places. This makes life easier for us because we only ever
3. have to change the name once, rather than every time it appears in the
4. spec file

1. usually we name non-e-smith-specific software with whatever its normal
2. name is. If we were doing the SME Server specific bits in a separate RPM,
3. we'd probably call it smeserver-PackageName

%define name smeserver-PackageName

1. now you'll see how we refer to a value we've set previously. If we
2. did "%define foo bar" we can use "%{foo}" to insert "bar" in that
3. place.

Name: %{name}

1. and some more of the same with version and release numbers.

Release: %{release}

1. The copyright should be "GPL" for any contrib module you hope to
2. make available for other SME Server users

Copyright: GPL

1. The Group should indicate the type of application you're packaging.
2. It is used to group RPMs logically in various user interfaces.
3. You can find a list of groups by looking at your current installed rpm
4. package documentation: /usr/share/doc/rpm-x.x.x/GROUPS

Group: Networking/Daemons

1. This is the name of the source file to use. Notice how we generate it
2. based on the name and version we set earlier?

Source: %{name}-%{version}.tar.gz

1. If you are using patch files, put some statements to define the
2. patch levels. You may wish to use the format:
3. PatchN: %{name}-%{version}-%{release}.identity_patch
4. where 'N' is the next small integer
5. where 'identity' references who you are, work for or represent.
6. This could be your abreviated companyname or personal initials.

Patch0: smeserver-PackageName-1.0.0-02.dtm_patch

1. The Packager is the name and email address of the person who packaged
2. this software for SME Server, who may be a different person to the one
3. who originally wrote it.

Packager: Fred Foonly <foonly@example.com>

1. Where to do the work of building the RPMs. This should be a temporary
2. directory unique to this package, hence we use the name, version and
3. release values we set earlier to make up the directory name

BuildRoot: /var/tmp/%{name}-%{version}-%{release}-buildroot

1. What architectures do we want to build this for? Use "i386" if your
2. software is compiled, or "noarch" if it will run on any platform
3. without compiling. Examples of the latter include software written in
4. Perl and many web applications. Most SME Server management RPMs should
5. be "noarch"

BuildArchitectures: noarch

1. What software is required to build the RPM? This lets the RPM program
2. figure out whether it will be able to build the RPM successfully.
3. You can either specify just the name of the software (eg "perl") or
4. specify a minimum version ("smeserver-devtools >= 0.1-3" means that this
5. software requires the package smeserver-devtools version 0.1-3 or higher
6. to run correctly.

BuildRequires: smeserver-devtools >= 0.1-3

1. What software is required for the RPM to run correctly once it's
2. installed on a system? This has the same format as BuildRequires

Requires: PackageName >= 2.2

1. typically, smeserver-PackageName will require PackageName, so you have to have
2. the base software installed before you can install the SME Server bits to
3. configure it

1. What software is required for the RPM to run correctly once it's
2. installed on a system? This has the same format as BuildRequires

Requires: PackageName >= 2.2

1. What software is obsolete and will be automatically uninstalled for this
2. RPM to run correctly once it's installed on a system?

Obsoletes: PackageName

1. The provides tag is used to specify a ‘virtual package’ that the packaged
2. software makes available when it is installed. Normally, this tag would
3. be used when different packages provide equivalent services.

Provides: PackageName

1. This turns off automatic dependency processing that can sometimes
2. cause problems

AutoReqProv: no

1. The description is a slightly more verbose version of the summary

%name

%name is an implementation of http://domain.com for the SME Server. This package has been integrated it into the SME Server and provides a server-manager panel for configuring it.

1. The changelog records changes made with each version. Make sure these
2. are in exactly the right format, otherwise the RPM will not build.

%changelog

• Tue Feb 20 2003 Fred Foonly <fred@example.com>

- [1.0.0-02] - Added new search widget to server-manager 'foo' panel - Fixed bar.conf template - no longer fails if 'baz' is uninitialized

• Thu Feb 8 2003 Fred Foonly <fred@example.com>

- [1.0.0-01] - Original version

1. The prep and setup sections describe what to do to prepare the source code
2. for building. For instance, this is where you would apply patches if
3. you were using them.

%setup

%patch0 -p1

1. The build section lists commands to run as part of the build process
2. This is where you can use a root/createlinks script to create events and
3. action links.

%build

perl createlinks

1. The install section lists commands to run during the build phase to
2. emulate the steps taken by "make install" in a non-RPM context. Keep
3. in mind that we don't actually want to install the software on our
4. development system, we want it installed into our BUILD directory.
5. The variable $RPM_BUILD_ROOT is available to us for convenience, to
6. refer to the directory rpms/BUILD/yourappname/root (or whatever's set
7. in the BuildRoot line near the top of this spec file.

%install

1. clean out the build root, to make sure nothing old is hanging around
2. in there

rm -rf $RPM_BUILD_ROOT

1. now we generate a file list so we know what's in the RPM; see the
2. %files section below for how it's actually used

(cd root ; /usr/bin/find . -depth -print | /bin/cpio -dump $RPM_BUILD_ROOT) /bin/rm -f %{name}-%{version}-filelist /sbin/e-smith/genfilelist $RPM_BUILD_ROOT > %{name}-%{version}-filelist

1. This section will help clear out the build root before
2. building the RPM

%clean

rm -rf $RPM_BUILD_ROOT

1. Now we have to list all the files that are part of our installed RPM
2. The %files statement lets us refer to an external file list that we
3. just generated, which is easier than trying to list them all by hand

%files -f %{name}-%{version}-filelist

1. The following line lets us specify attributes for the files to
2. be installed. Specifically, we can specify the mode (permissions),
3. owner, and group. If we want any of them to default to whatever's
4. already in the build root, we can just use a dash. In most cases,
5. you'll want to leave the permissions as they are, but make the files
6. owned by user and group root

%defattr(-,root,root)

1. The preun section lists commands to run prior to uninstalling the software
2. on the SME Server. This may mean things like signalling events or
3. running action scripts

%preun

1. The postun section lists commands to run after uninstalling the software
2. on the SME Server. This may mean things like signalling events or
3. running action scripts

%postun

1. The pre section lists commands to run prior to installing the software
2. on the e-smith system. This may mean things like signalling e-smith
3. events or running action scripts

%pre

1. The post section lists commands to run after installing the software
2. on the e-smith system. This may mean things like signalling e-smith
3. events or running action scripts