User Tools

Site Tools


spec_file_notes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

spec_file_notes [2015/05/07 20:11]
stephdl [perl createlinks]
spec_file_notes [2019/06/05 21:48]
Line 1: Line 1:
-===== .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} ==== 
- 
-  # 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 [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 
- 
-==== 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 
- 
-  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)'​ \ 
-    $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 ==== 
-{{tag> rpm }} 
  
spec_file_notes.txt · Last modified: 2019/06/05 21:48 (external edit)