|
|
|
Copyright © Darrell May <dmay@myezserver.com> SME Server release
supported:
all Contributors: Charlie
Brady and the authors of the following documents: |
|
|
|
RPM
Naming Convention Examples
of e-smith core rpms following recommend e-smith naming convention and releaseID tag below: e-smith-email-4.14.0-07dmay.noarch.rpm Examples
of community contributed rpms following the recommended smeserver naming
convention and releaseID tag below: smeserver-webshare-1.0.0-1dmay.noarch.rpm |
|
|
STEP 1: Via the server-manager create an unprivileged user named rpmmaker. Be sure to set a password for this user.
STEP 2: Now you will need to give this
user a shell to work with. This requires root console login.
|
# login root Password: xxxxxxxx Welcome to the Mitel Networks SME Server. [root@test root]# chsh -s /bin/bash rpmmaker Changing shell for rpmmaker. Shell changed. |
STEP 3:
Login as the new user:
|
[root@test root]#
login rpmmaker Password: xxxxxxxx Welcome to the Mitel Networks SME Server. |
STEP 4: Note the home directory:
|
bash-2.05a$ pwd /home/e-smith/files/users/rpmmaker |
STEP 5: Now we need to set up an RPM
sandbox within this user's space.
|
bash-2.05a$ mkdir -p
$HOME/rpms/{SRPMS,BUILD,SPECS,SOURCES,RPMS,lib} bash-2.05a$ mkdir -p
$HOME/rpms/RPMS/{i386,noarch} bash-2.05a$ echo "%_topdir
$HOME/rpms" > $HOME/.rpmmacros |
STEP 6: Download and install the srpm you wish to revise. In this example we will use
e-smith-email-4.14.0-06.src.rpm.
|
bash-2.05a$ cd
$HOME/rpms bash-2.05a$ rpm -Uvh
e-smith-email-4.14.0-06.src.rpm
1:e-smith-email
################################## [100%] |
STEP 7: Note the
name of the spec file:
|
bash-2.05a$ ls -1
$HOME/rpms/SPECS e-smith-email-4.14.0.spec |
STEP 8: Create
a pristine copy of the BUILD source including all patches to 'revise':
|
bash-2.05a$ rpmbuild -bp
$HOME/rpms/SPECS/e-smith-email-4.14.0.spec |
STEP 9: Note
the name of the BUILD source:
|
bash-2.05a$ ls -1 $HOME/rpms/BUILD e-smith-email-4.14.0 |
STEP 10: Change
the name to your new release (-07 in this example)
|
bash-2.05a$ mv
$HOME/rpms/BUILD/e-smith-email-4.14.0 $HOME/rpms/BUILD/e-smith-email-4.14.0-07 |
STEP 11: Create
a pristine copy of the BUILD source including all patches to 'reference':
|
bash-2.05a$ rpmbuild -bp
$HOME/rpms/SPECS/e-smith-email-4.14.0.spec |
STEP 12: Edit
the BUILD you wish to revise
|
bash-2.05a$ cd
$HOME/rpms/BUILD/e-smith-email-4.14.0-07 bash-2.05a$
mc …and off you go! |
STEP 13: Create
your patch showing the differences between the original and your revision:
|
bash-2.05a$ cd $HOME/rpms/BUILD bash-2.05a$ diff -ruN e-smith-email-4.14.{0,0-07} >
$HOME/rpms/SOURCES/e-smith-email-4.14.0-07.ID_patch |
General Note: diff command
options:
-r = Recursively compare any subdirectories found.
-u = Output NUM (default 2) lines of unified context.
-N = Treat absent files as empty.
ID = your identity, such as personal or company initials
STEP 14: Edit
the spec file. In this example:
|
bash-2.05a$ cd $HOME/rpms/SPECS bash-2.05a$ chmod 660
e-smith-email-4.14.0.spec bash-2.05a$ pico
e-smith-email-4.14.0.spec |
Examples:
|
%define release 07 Vendor: contribs.org Patch4: e-smith-email-4.14.0-07.dmay_patch %changelog * Tue - [4.14.0-07] - BugFix /etc/e-smith/db/accounts/defaults/everyone/Visible %prep %patch4 -p1 |
General
Note:
Add "PatchN:
smeserver-package-x.x.x-x.ID_patch" to the
header
Add "%patchN
-p1" to the %prep section
(where 'N' is the
next small integer)
(where 'ID'
references who you are, work for or represent)
STEP 15: Build
the new release:
|
bash-2.05a$ rpmbuild -ba
e-smith-email-4.14.0.spec |
STEP 16: Test
internally and when ready release the rpm/src to the
community test repository.
Appendix –
A:
.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
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 -
[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 -
[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 |
Appendix – B: buildrpm script
used for building new rpms.
|
#!/bin/sh # Usage: ./buildrpm
%{name}-%{version} # Example: ./buildrpm
smeserver-package-0.0.1 cd $HOME/rpms/SOURCES && \
test -d $1 && \
tar zcvf $1.tar.gz $1 rpmbuild -ba
$HOME/rpms/SPECS/$1.spec |
Appendix – C: root/creatlinks
example script
|
#!/usr/bin/perl -w sub
safe_symlink { my ($from, $to) = @_; use File::Basename; use File::Path; mkpath(dirname($to)); unlink($to); symlink($from, $to) or die
"Can't create symlink from $from to $to:
$!"; } sub
panel_link { my ($function, $panel) =
@_; safe_symlink("../../../functions/$function",
"root/etc/e-smith/web/panels/$panel/cgi-bin/$function"); } sub
event_link { my ($action, $event,
$level) = @_; safe_symlink("../actions/${action}",
"root/etc/e-smith/events/${event}/S${level}${action}"); } #-------------------------------------------------- #
functions for manager panel #-------------------------------------------------- panel_link("yum",
"manager"); #-------------------------------------------------- #
actions for yum-update event #-------------------------------------------------- event_link("initialize-default-databases",
"yum-update", "10"); event_link("conf-yum",
"yum-update", "20"); event_link("yum-arch-repository",
"yum-update", "30"); event_link("yum-check-repository",
"yum-update", "40"); |