5,576
edits
Changes
Jump to navigation
Jump to search
== .Spec file Notes ==
# This is a revision of:
# http://www.e-smith.org/docs/howto/building-contribs-example.spec
# This is an example spec file for SME Server rpm building.
# The Summary line is a single line description of the module.
=== 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 ===
# now you'll see how we refer to a value we've set previously. If we
# 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} ===
# The copyright should be "GPL" for any contrib module you hope to
# make available for other SME Server users
=== Copyright: GPL ===
# The Group should indicate the type of application you're packaging.
# It is used to group RPMs logically in various user interfaces.
# 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 ===
# 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 ===
# 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 ===
# What software is required to build the RPM? This lets the RPM program
# 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 ===
# What software is required for the RPM to run correctly once it's
# installed on a system? This has the same format as BuildRequires
=== Requires: PackageName >= 2.2 ===
# typically, smeserver-PackageName will require PackageName, so you have to have
# the base software installed before you can install the SME Server bits to
# configure it
# What software is required for the RPM to run correctly once it's
# installed on a system? This has the same format as BuildRequires
=== 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?
=== Obsoletes: PackageName ===
# 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 ===
# This turns off automatic dependency processing that can sometimes
# cause problems
=== AutoReqProv: no ===
# The description is a slightly more verbose version of the summary
=== %description ===
=== %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.
# The changelog records changes made with each version. Make sure these
# 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
# The prep and setup sections describe what to do to prepare the source code
# for building. For instance, this is where you would apply patches if
# you were using them.
=== %prep ===
=== %setup ===
==== %patch0 -p1 ====
# The build section lists commands to run as part of the build process
# This is where you can use a root/createlinks script to create events and
# action links.
=== %build ===
==== perl createlinks ====
# The install section lists commands to run during the build phase to
# 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.
=== %install ===
# clean out the build root, to make sure nothing old is hanging around
# in there
rm -rf $RPM_BUILD_ROOT
# 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
(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
# This section will help clear out the build root before
# building the RPM
=== %clean ===
rm -rf $RPM_BUILD_ROOT
# 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
# be installed. Specifically, we can specify the mode (permissions),
# 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)
# The preun section lists commands to run prior to uninstalling the software
# on the SME Server. This may mean things like signalling events or
# running action scripts
=== %preun ===
# 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
=== %postun ===
# 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
# events or running action scripts
=== %pre ===
# The post section lists commands to run after installing the software
# on the e-smith system. This may mean things like signalling e-smith
# events or running action scripts
=== %post ===
[[Category:Howto]]
[[Category:SME Server Development Framework]]
[[Category:Development Tools]]
[[Category:SME9-Development]]
Created page with " == .Spec file Notes == # This is a revision of: # http://www.e-smith.org/docs/howto/building-contribs-example.spec # This is an example spec file for SME Server rpm building...."
== .Spec file Notes ==
# This is a revision of:
# http://www.e-smith.org/docs/howto/building-contribs-example.spec
# This is an example spec file for SME Server rpm building.
# The Summary line is a single line description of the module.
=== 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 ===
# now you'll see how we refer to a value we've set previously. If we
# 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} ===
# The copyright should be "GPL" for any contrib module you hope to
# make available for other SME Server users
=== Copyright: GPL ===
# The Group should indicate the type of application you're packaging.
# It is used to group RPMs logically in various user interfaces.
# 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 ===
# 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 ===
# 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 ===
# What software is required to build the RPM? This lets the RPM program
# 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 ===
# What software is required for the RPM to run correctly once it's
# installed on a system? This has the same format as BuildRequires
=== Requires: PackageName >= 2.2 ===
# typically, smeserver-PackageName will require PackageName, so you have to have
# the base software installed before you can install the SME Server bits to
# configure it
# What software is required for the RPM to run correctly once it's
# installed on a system? This has the same format as BuildRequires
=== 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?
=== Obsoletes: PackageName ===
# 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 ===
# This turns off automatic dependency processing that can sometimes
# cause problems
=== AutoReqProv: no ===
# The description is a slightly more verbose version of the summary
=== %description ===
=== %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.
# The changelog records changes made with each version. Make sure these
# 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
# The prep and setup sections describe what to do to prepare the source code
# for building. For instance, this is where you would apply patches if
# you were using them.
=== %prep ===
=== %setup ===
==== %patch0 -p1 ====
# The build section lists commands to run as part of the build process
# This is where you can use a root/createlinks script to create events and
# action links.
=== %build ===
==== perl createlinks ====
# The install section lists commands to run during the build phase to
# 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.
=== %install ===
# clean out the build root, to make sure nothing old is hanging around
# in there
rm -rf $RPM_BUILD_ROOT
# 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
(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
# This section will help clear out the build root before
# building the RPM
=== %clean ===
rm -rf $RPM_BUILD_ROOT
# 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
# be installed. Specifically, we can specify the mode (permissions),
# 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)
# The preun section lists commands to run prior to uninstalling the software
# on the SME Server. This may mean things like signalling events or
# running action scripts
=== %preun ===
# 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
=== %postun ===
# 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
# events or running action scripts
=== %pre ===
# The post section lists commands to run after installing the software
# on the e-smith system. This may mean things like signalling e-smith
# events or running action scripts
=== %post ===
[[Category:Howto]]
[[Category:SME Server Development Framework]]
[[Category:Development Tools]]
[[Category:SME9-Development]]