Difference between revisions of ".spec file notes"

From SME Server
Jump to navigationJump to search
 
(46 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
 
+
{{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:
Line 10: Line 10:
 
  # 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
 
  # anything starting with a % sign is a command that is interpreted by
Line 25: Line 24:
 
  # name is. If we were doing the SME Server specific bits in a separate RPM,
 
  # name is. If we were doing the SME Server specific bits in a separate RPM,
 
  # we'd probably call it smeserver-PackageName
 
  # we'd probably call it smeserver-PackageName
−
 
+
==== %define name smeserver-PackageName ====
−
=== %define name smeserver-PackageName ===
 
  
 
  # now you'll see how we refer to a value we've set previously.  If we
 
  # 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
 
  # did "%define foo bar" we can use "%{foo}" to insert "bar" in that
 
  # place.
 
  # place.
−
 
+
==== Name: %{name} ====
−
=== Name: %{name} ===
 
 
   
 
   
 
  # and some more of the same with version and release numbers.
 
  # and some more of the same with version and release numbers.
 +
==== %define version 1.0.0 ====
 +
==== %define release 02 ====
  
−
=== %define version 1.0.0 ===
+
==== Version: %{version} ====
−
=== %define release 02 ===
+
==== Release: %{release}%{?dist} ====
−
=== Version: %{version} ===
 
−
=== Release: %{release} ===
 
  
 
  # The copyright should be "GPL" for any contrib module you hope to
 
  # The copyright should be "GPL" for any contrib module you hope to
 
  # make available for other SME Server users
 
  # make available for other SME Server users
−
=== Copyright: GPL ===
+
 
 +
==== Copyright: GPL ====
  
 
  # The Group should indicate the type of application you're packaging.
 
  # The Group should indicate the type of application you're packaging.
Line 49: Line 47:
 
  # You can find a list of groups by looking at your current installed rpm
 
  # You can find a list of groups by looking at your current installed rpm
 
  # package documentation: /usr/share/doc/rpm-x.x.x/GROUPS
 
  # package documentation: /usr/share/doc/rpm-x.x.x/GROUPS
−
=== Group: Networking/Daemons ===
+
==== Group: Networking/Daemons ====
  
 
  # This is the name of the source file to use.  Notice how we generate it
 
  # This is the name of the source file to use.  Notice how we generate it
 
  # based on the name and version we set earlier?
 
  # based on the name and version we set earlier?
−
=== Source: %{name}-%{version}.tar.gz ===
+
==== Source: %{name}-%{version}.tar.gz ====
  
 
  # If you are using patch files, put some statements to define the
 
  # If you are using patch files, put some statements to define the
Line 61: Line 59:
 
  # where 'identity' references who you are, work for or represent.
 
  # where 'identity' references who you are, work for or represent.
 
  # This could be your abreviated companyname or personal initials.
 
  # This could be your abreviated companyname or personal initials.
−
#
+
==== Patch0: smeserver-PackageName-1.0.0-02.dtm_patch ====
−
=== Patch0: smeserver-PackageName-1.0.0-02.dtm_patch ===
 
 
   
 
   
 
  # The Packager is the name and email address of the person who packaged
 
  # 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
 
  # this software for SME Server, who may be a different person to the one
 
  # who originally wrote it.
 
  # who originally wrote it.
−
=== Packager: Fred Foonly <foonly@example.com> ===
+
==== Packager: Fred Foonly <foonly@example.com> ====
 
   
 
   
 
  # Where to do the work of building the RPMs.  This should be a temporary
 
  # 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
 
  # directory unique to this package, hence we use the name, version and
 
  # release values we set earlier to make up the directory name
 
  # release values we set earlier to make up the directory name
−
=== BuildRoot: /var/tmp/%{name}-%{version}-%{release}-buildroot ===
+
==== BuildRoot: /var/tmp/%{name}-%{version}-%{release}-buildroot ====
 
   
 
   
 
  # What architectures do we want to build this for?  Use "i386" if your
 
  # What architectures do we want to build this for?  Use "i386" if your
Line 79: Line 76:
 
  # Perl and many web applications.  Most SME Server management RPMs should
 
  # Perl and many web applications.  Most SME Server management RPMs should
 
  # be "noarch"
 
  # be "noarch"
−
=== BuildArchitectures: noarch ===
+
==== BuildArchitectures: noarch ====
  
 
  # What software is required to build the RPM?  This lets the RPM program
 
  # What software is required to build the RPM?  This lets the RPM program
Line 87: Line 84:
 
  # software requires the package smeserver-devtools version 0.1-3 or higher
 
  # software requires the package smeserver-devtools version 0.1-3 or higher
 
  # to run correctly.
 
  # to run correctly.
−
=== BuildRequires: smeserver-devtools >= 0.1-3 ===
+
==== BuildRequires: smeserver-devtools >= 0.1-3 ====
  
 
  # What software is required for the RPM to run correctly once it's
 
  # What software is required for the RPM to run correctly once it's
 
  # installed on a system?  This has the same format as BuildRequires
 
  # installed on a system?  This has the same format as BuildRequires
−
=== Requires: PackageName >= 2.2 ===
+
==== Requires: PackageName >= 2.2 ====
  
 
  # typically, smeserver-PackageName will require PackageName, so you have to have
 
  # typically, smeserver-PackageName will require PackageName, so you have to have
Line 99: Line 96:
 
  # What software is required for the RPM to run correctly once it's
 
  # What software is required for the RPM to run correctly once it's
 
  # installed on a system?  This has the same format as BuildRequires
 
  # installed on a system?  This has the same format as BuildRequires
−
=== Requires: PackageName >= 2.2 ===
+
==== Requires: PackageName >= 2.2 ====
  
 
  # What software is obsolete and will be automatically uninstalled for this
 
  # What software is obsolete and will be automatically uninstalled for this
 
  # RPM to run correctly once it's installed on a system?
 
  # RPM to run correctly once it's installed on a system?
−
=== Obsoletes: PackageName ===
+
==== Obsoletes: PackageName ====
  
 
  # The provides tag is used to specify a ‘virtual package’ that the packaged
 
  # The provides tag is used to specify a ‘virtual package’ that the packaged
 
  # software makes available when it is installed. Normally, this tag would
 
  # software makes available when it is installed. Normally, this tag would
 
  # be used when different packages provide equivalent services.
 
  # be used when different packages provide equivalent services.
−
=== Provides: PackageName ===
+
==== Provides: PackageName ====
  
 
  # This turns off automatic dependency processing that can sometimes
 
  # This turns off automatic dependency processing that can sometimes
 
  # cause problems
 
  # cause problems
−
=== AutoReqProv: no ===
+
==== AutoReqProv: no ====
  
 
  # The description is a slightly more verbose version of the summary
 
  # The description is a slightly more verbose version of the summary
−
=== %description ===
+
==== %description ====
−
=== %name ===
+
==== %name ====
 
  # %name is an implementation of http://domain.com for the SME Server.
 
  # %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
 
  #This package has been integrated it into the SME Server and provides a
Line 123: Line 120:
 
  # The changelog records changes made with each version.  Make sure these
 
  # The changelog records changes made with each version.  Make sure these
 
  # are in exactly the right format, otherwise the RPM will not build.
 
  # are in exactly the right format, otherwise the RPM will not build.
−
 
+
==== %changelog ====
−
=== %changelog ===
 
  
 
  * Tue Feb 20 2003 Fred Foonly <fred@example.com>
 
  * Tue Feb 20 2003 Fred Foonly <fred@example.com>
Line 134: Line 130:
 
  - [1.0.0-01]
 
  - [1.0.0-01]
 
  - Original version  
 
  - Original version  
−
+
 
 
  # The prep and setup sections describe what to do to prepare the source code
 
  # 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
 
  # for building.  For instance, this is where you would apply patches if
 
  # you were using them.
 
  # you were using them.
  
−
=== %prep ===
+
==== %prep ====
−
=== %setup ===
+
 
−
==== %patch0 -p1 ====
+
==== %setup ====
 +
===== %patch0 -p1 =====
  
 
  # The build section lists commands to run as part of the build process
 
  # 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
 
  # This is where you can use a root/createlinks script to create events and
−
  # action links.
+
  # 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
  
 +
==== %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
  
−
=== %build ===
+
===== perl createlinks =====
−
==== perl createlinks ====
 
  
 
  # The install section lists commands to run during the build phase to
 
  # The install section lists commands to run during the build phase to
Line 159: Line 161:
 
  # in the BuildRoot line near the top of this spec file.
 
  # in the BuildRoot line near the top of this spec file.
  
−
=== %install ===
+
==== %install ====
 
  # clean out the build root, to make sure nothing old is hanging around
 
  # clean out the build root, to make sure nothing old is hanging around
 
  # in there
 
  # in there
−
rm -rf $RPM_BUILD_ROOT
 
−
 
 
  # now we generate a file list so we know what's in the RPM; see the
 
  # 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
 
  # %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)
 
  (cd root  ; /usr/bin/find . -depth -print | /bin/cpio -dump $RPM_BUILD_ROOT)
−
  /bin/rm -f %{name}-%{version}-filelist
+
  /sbin/e-smith/genfilelist  \
−
/sbin/e-smith/genfilelist $RPM_BUILD_ROOT > %{name}-%{version}-filelist
+
    '''--dir /var/lib/packageName/tmp 'attr(0770,root,www)' \'''
−
   
+
    --dir /var/service/tinydns 'attr(0755,root,root)' \
−
  # This section will help clear out the build root before
+
    --dir /var/service/tinydns/log 'attr(0755,root,root)' \
−
  # building the RPM
+
    --file /var/service/tinydns/run 'attr(0750,root,root)' \
−
=== %clean ===
+
    --file /var/service/tinydns/tinydns-log.pl 'attr(0750,root,root)' \
−
  rm -rf $RPM_BUILD_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
 +
 
 +
  # we can push file to a destination in order to use them after in a mysql.init script
 +
  # the file needs to be outside of the root/ of your rpm
 +
  # 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
 
  # 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
 
  # 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
 
  # just generated, which is easier than trying to list them all by hand
  
−
%files -f %{name}-%{version}-filelist
+
==== %files -f %{name}-%{version}-filelist ====
  
 
  # The following line lets us specify attributes for the files to
 
  # The following line lets us specify attributes for the files to
Line 187: Line 209:
 
  # you'll want to leave the permissions as they are, but make the files
 
  # you'll want to leave the permissions as they are, but make the files
 
  # owned by user and group root
 
  # owned by user and group root
−
+
 
−
%defattr(-,root,root)
+
====%defattr(-,root,root)====
−
   
+
====%attr(755,root,root) /etc/e-smith/sql/init/sme8admin====
 +
 
 +
# This section will help clear out the build root before
 +
  # building the RPM
 +
 
 +
==== %clean ====
 +
rm -rf $RPM_BUILD_ROOT
 +
 
 
  # The preun section lists commands to run prior to uninstalling the software
 
  # The preun section lists commands to run prior to uninstalling the software
 
  # on the SME Server. This may mean things like signalling events or
 
  # on the SME Server. This may mean things like signalling events or
 
  # running action scripts
 
  # running action scripts
−
=== %preun ===
+
 
 +
==== %preun ====
  
 
  # The postun section lists commands to run after uninstalling the software
 
  # The postun section lists commands to run after uninstalling the software
 
  # on the SME Server. This may mean things like signalling events or
 
  # on the SME Server. This may mean things like signalling events or
 
  # running action scripts
 
  # running action scripts
−
=== %postun ===
+
==== %postun ====
  
 
  # The pre section lists commands to run prior to installing the software
 
  # 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
 
  # on the e-smith system.  This may mean things like signalling e-smith
 
  # events or running action scripts
 
  # events or running action scripts
−
=== %pre ===
+
==== %pre ====
 +
/sbin/e-smith/create-system-user dns 53 "Name server" /var/service/tinydns /bin/false
 +
/sbin/e-smith/create-system-user dnslog 411 "DNS log user" /var/log /bin/false
  
 
  # The post section lists commands to run after installing the software
 
  # The post section lists commands to run after installing the software
 
  # on the e-smith system. This may mean things like signalling e-smith
 
  # on the e-smith system. This may mean things like signalling e-smith
 
  # events or running action scripts
 
  # events or running action scripts
−
=== %post ===
+
 
−
[[Category:Howto]]
+
==== %post ====
 +
 
 
[[Category:SME Server Development Framework]]
 
[[Category:SME Server Development Framework]]
 
[[Category:Development Tools]]
 
[[Category:Development Tools]]
 
[[Category:SME9-Development]]
 
[[Category:SME9-Development]]

Latest revision as of 14:07, 11 October 2020

PythonIcon.png Skill level: Developer
Risk of inconsistencies with Koozali SME Server methodology, upgrades & functionality is high. One must be knowledgeable about how changes impact their Koozali SME Server. Significant risk of irreversible harm.


.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.

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:
# 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}%{?dist}

# 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. see Createlinks_example_script 
# and Esmith::Build::CreateLinks for more information

%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
# 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
# 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

# we can push file to a destination in order to use them after in a mysql.init script
# the file needs to be outside of the root/ of your rpm
# 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
# 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)

%attr(755,root,root) /etc/e-smith/sql/init/sme8admin

# This section will help clear out the build root before
# building the RPM

%clean

rm -rf $RPM_BUILD_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

/sbin/e-smith/create-system-user dns 53 "Name server" /var/service/tinydns /bin/false
/sbin/e-smith/create-system-user dnslog 411 "DNS log user" /var/log /bin/false

# 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

Retrieved from "https://wiki.koozali.org/index.php?title=.spec_file_notes&oldid=38881"