859
edits
Changes
From SME Server
Jump to navigationJump to search→%install
{{Level|Developer}}
== .Spec file Notes ==
== .Spec file Notes ==
The "Recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" suffix and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.
The "Recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" suffix and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code.
Spec files are usually distributed within SRPM files, which contain the spec file packaged along with the source code. More information about building RPMs can be found at http://www.rpm.org/wiki/Docs#PackagerDocumentation
# This is a revision of:
# This is a revision of:
# http://www.e-smith.org/docs/howto/building-contribs-example.spec
# http://www.e-smith.org/docs/howto/building-contribs-example.spec
# This is an example spec file for SME Server rpm building.
# This is an example spec file for SME Server rpm building.
# The Summary line is a single line description of the module.
# The Summary line is a single line description of the module.
==== Summary: PackageName for SME Server ====
=== Summary: PackageName for SME Server ===
# anything starting with a % sign is a command that is interpreted by
# the RPM program. Using % commands we can set values and use them
# again later.
# here we define a base name for the module, which will get used in
# various places. This makes life easier for us because we only ever
# have to change the name once, rather than every time it appears in the
# spec file
# usually we name non-e-smith-specific software with whatever its normal
# name is. If we were doing the SME Server specific bits in a separate RPM,
# we'd probably call it smeserver-PackageName
==== %define name smeserver-PackageName ====
# anything starting with a % sign is a command that is interpreted by
# now you'll see how we refer to a value we've set previously. If we
# the RPM program. Using % commands we can set values and use them
# did "%define foo bar" we can use "%{foo}" to insert "bar" in that
# place.
==== Name: %{name} ====
# and some more of the same with version and release numbers.
==== %define version 1.0.0 ====
==== %define release 02 ====
==== Version: %{version} ====
==== Release: %{release}%{?dist} ====
# usually we name non-e-smith-specific software with whatever its normal
# The copyright should be "GPL" for any contrib module you hope to
# name is. If we were doing the SME Server specific bits in a separate RPM,
# make available for other SME Server users
=== %define name smeserver-PackageName ===
==== Copyright: GPL ====
# now you'll see how we refer to a value we've set previously. If we
# The Group should indicate the type of application you're packaging.
# did "%define foo bar" we can use "%{foo}" to insert "bar" in that
# It is used to group RPMs logically in various user interfaces.
# place.
# You can find a list of groups by looking at your current installed rpm
# package documentation: /usr/share/doc/rpm-x.x.x/GROUPS
==== Group: Networking/Daemons ====
=== Name: %{name} ===
# This is the name of the source file to use. Notice how we generate it
# based on the name and version we set earlier?
==== Source: %{name}-%{version}.tar.gz ====
# If you are using patch files, put some statements to define the
# patch levels. You may wish to use the format:
# PatchN: %{name}-%{version}-%{release}.identity_patch
# where 'N' is the next small integer
# where 'identity' references who you are, work for or represent.
# This could be your abreviated companyname or personal initials.
==== Patch0: smeserver-PackageName-1.0.0-02.dtm_patch ====
# and some more of the same with version and release numbers.
# The Packager is the name and email address of the person who packaged
# this software for SME Server, who may be a different person to the one
# who originally wrote it.
==== Packager: Fred Foonly <foonly@example.com> ====
# Where to do the work of building the RPMs. This should be a temporary
# directory unique to this package, hence we use the name, version and
# release values we set earlier to make up the directory name
==== BuildRoot: /var/tmp/%{name}-%{version}-%{release}-buildroot ====
# What architectures do we want to build this for? Use "i386" if your
# software is compiled, or "noarch" if it will run on any platform
# without compiling. Examples of the latter include software written in
# Perl and many web applications. Most SME Server management RPMs should
# be "noarch"
==== BuildArchitectures: noarch ====
=== %define version 1.0.0 ===
# What software is required to build the RPM? This lets the RPM program
=== %define release 02 ===
# figure out whether it will be able to build the RPM successfully.
# You can either specify just the name of the software (eg "perl") or
# specify a minimum version ("smeserver-devtools >= 0.1-3" means that this
# software requires the package smeserver-devtools version 0.1-3 or higher
# to run correctly.
==== BuildRequires: smeserver-devtools >= 0.1-3 ====
# The copyright should be "GPL" for any contrib module you hope to
# What software is required for the RPM to run correctly once it's
# make available for other SME Server users
# installed on a system? This has the same format as BuildRequires
=== Copyright: GPL ===
==== Requires: PackageName >= 2.2 ====
# The Group should indicate the type of application you're packaging.
# typically, smeserver-PackageName will require PackageName, so you have to have
# the base software installed before you can install the SME Server bits to
# You can find a list of groups by looking at your current installed rpm
# configure it
# package documentation: /usr/share/doc/rpm-x.x.x/GROUPS
# This is the name of the source file to use. Notice how we generate it
# What software is required for the RPM to run correctly once it's
# based on the name and version we set earlier?
# installed on a system? This has the same format as BuildRequires
=== Source: %{name}-%{version}.tar.gz ===
==== Requires: PackageName >= 2.2 ====
# What software is obsolete and will be automatically uninstalled for this
# RPM to run correctly once it's installed on a system?
# PatchN: %{name}-%{version}-%{release}.identity_patch
==== Obsoletes: PackageName ====
# What architectures do we want to build this for? Use "i386" if your
=== BuildArchitectures: noarch ===
# What software is required to build the RPM? This lets the RPM program
# The provides tag is used to specify a ‘virtual package’ that the packaged
# software makes available when it is installed. Normally, this tag would
# be used when different packages provide equivalent services.
==== Provides: PackageName ====
# software requires the package smeserver-devtools version 0.1-3 or higher
# to run correctly.
=== BuildRequires: smeserver-devtools >= 0.1-3 ===
# What software is required for the RPM to run correctly once it's
# This turns off automatic dependency processing that can sometimes
# installed on a system? This has the same format as BuildRequires
# cause problems
=== Requires: PackageName >= 2.2 ===
==== AutoReqProv: no ====
# typically, smeserver-PackageName will require PackageName, so you have to have
# The description is a slightly more verbose version of the summary
# the base software installed before you can install the SME Server bits to
==== %description ====
# configure it
==== %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.
# What software is required for the RPM to run correctly once it's
# The changelog records changes made with each version. Make sure these
# installed on a system? This has the same format as BuildRequires
# are in exactly the right format, otherwise the RPM will not build.
=== Requires: PackageName >= 2.2 ===
==== %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
# The provides tag is used to specify a ‘virtual package’ that the packaged
# The prep and setup sections describe what to do to prepare the source code
# software makes available when it is installed. Normally, this tag would
# for building. For instance, this is where you would apply patches if
# be used when different packages provide equivalent services.
# you were using them.
==== %prep ====
=== AutoReqProv: no ===
==== %setup ====
=== %description ===
===== %patch0 -p1 =====
=== %name ===
# The changelog records changes made with each version. Make sure these
# The build section lists commands to run as part of the build process
# are in exactly the right format, otherwise the RPM will not build.
# This is where you can use a root/createlinks script to create events and
# action links. see [http://wiki.contribs.org/Createlinks_example_script Createlinks_example_script]
# and [http://wiki.contribs.org/Esmith::Build::CreateLinks Esmith::Build::CreateLinks] for more information
=== %changelog ===
==== %build ====
# A cool way for creating a directory called '''tmp''' during the rpm installation
=====%{__mkdir_p} root/var/lib/packageName/tmp=====
or
%{__mkdir} -p $RPM_BUILD_ROOT/var/log/httpd-bkpc
===== perl createlinks =====
# The install section lists commands to run during the build phase to
- [1.0.0-01]
# emulate the steps taken by "make install" in a non-RPM context. Keep
# in mind that we don't actually want to install the software on our
# development system, we want it installed into our BUILD directory.
# The variable $RPM_BUILD_ROOT is available to us for convenience, to
# refer to the directory rpms/BUILD/yourappname/root (or whatever's set
# in the BuildRoot line near the top of this spec file.
# The prep and setup sections describe what to do to prepare the source code
==== %install ====
# for building. For instance, this is where you would apply patches if
# clean out the build root, to make sure nothing old is hanging around
# you were using them.
# in there
# now we generate a file list so we know what's in the RPM; see the
# %files section below for how it's actually used
# A you can see below we set permissions and ownership on files and directories
# You can also ignore adding a directory with --ignoredir
rm -rf $RPM_BUILD_ROOT
rm -f %{name}-%{version}-filelist
(cd root ; /usr/bin/find . -depth -print | /bin/cpio -dump $RPM_BUILD_ROOT)
/sbin/e-smith/genfilelist \
'''--dir /var/lib/packageName/tmp 'attr(0770,root,www)' \'''
--dir /var/service/tinydns 'attr(0755,root,root)' \
--dir /var/service/tinydns/log 'attr(0755,root,root)' \
--file /var/service/tinydns/run 'attr(0750,root,root)' \
--file /var/service/tinydns/tinydns-log.pl 'attr(0750,root,root)' \
--file /var/service/tinydns/tinydns-readstats 'attr(0750,root,root)' \
--file /var/service/tinydns/control/1 'attr(0750,root,root)' \
--file /var/service/tinydns/control/2 'attr(0750,root,root)' \
--file /var/service/tinydns/log/run 'attr(0750,root,root)' \
--dir /var/log/tinydns 'attr(02755,dnslog,dnslog)' \
--file /var/service/dhcp-dns/dhcp-dns 'attr(0750,root,root)' \
--file /var/service/dhcp-dns/run 'attr(0750,root,root)' \
--ignoredir /etc/sudoers.d \
$RPM_BUILD_ROOT > %{name}-%{version}-%{release}-filelist
# The build section lists commands to run as part of the build process
# we can push file to a destination in order to use them after in a mysql.init script
# This is where you can use a root/createlinks script to create events and
# the file needs to be outside of the root/ of your rpm
# action links.
# for example :
# my $dbstruct = `rpm -qd smeserver-packageName | grep packageName.sql`;
# /usr/bin/mysql $db < $dbstruct
echo "%doc CHANGELOG.git" >> %{name}-%{version}-filelist
echo "%doc packageName.sql" >> %{name}-%{version}-filelist
# Now we have to list all the files that are part of our installed RPM
# The %files statement lets us refer to an external file list that we
# just generated, which is easier than trying to list them all by hand
==== %files -f %{name}-%{version}-filelist ====
# The following line lets us specify attributes for the files to
# clean out the build root, to make sure nothing old is hanging around
# be installed. Specifically, we can specify the mode (permissions),
# in there
# owner, and group. If we want any of them to default to whatever's
# already in the build root, we can just use a dash. In most cases,
# you'll want to leave the permissions as they are, but make the files
# owned by user and group root
====%defattr(-,root,root)====
====%attr(755,root,root) /etc/e-smith/sql/init/sme8admin====
# now we generate a file list so we know what's in the RPM; see the
# This section will help clear out the build root before
# %files section below for how it's actually used
# building the RPM
==== %clean ====
rm -rf $RPM_BUILD_ROOT
=== %clean ===
rm -rf $RPM_BUILD_ROOT
# Now we have to list all the files that are part of our installed RPM
# The preun section lists commands to run prior to uninstalling the software
# The %files statement lets us refer to an external file list that we
# on the SME Server. This may mean things like signalling events or
# just generated, which is easier than trying to list them all by hand
# running action scripts
%files -f %{name}-%{version}-filelist
==== %preun ====
# The following line lets us specify attributes for the files to
# The postun section lists commands to run after uninstalling the software
# on the SME Server. This may mean things like signalling events or
# running action scripts
# already in the build root, we can just use a dash. In most cases,
==== %postun ====
# you'll want to leave the permissions as they are, but make the files
# The pre section lists commands to run prior to installing the software
# on the e-smith system. This may mean things like signalling e-smith
# The preun section lists commands to run prior to uninstalling the software
# events or running action scripts
# on the SME Server. This may mean things like signalling events or
==== %pre ====
/sbin/e-smith/create-system-user dns 53 "Name server" /var/service/tinydns /bin/false
=== %preun ===
/sbin/e-smith/create-system-user dnslog 411 "DNS log user" /var/log /bin/false
# The postun section lists commands to run after uninstalling the software
# The post section lists commands to run after installing the software
# on the SME Server. This may mean things like signalling events or
# on the e-smith system. This may mean things like signalling e-smith
# events or running action scripts
==== %post ====
=== %pre ===
[[Category:SME Server Development Framework]]
[[Category:SME Server Development Framework]]
[[Category:Development Tools]]
[[Category:Development Tools]]
[[Category:SME9-Development]]
[[Category:SME9-Development]]
