RPM - Preface
Preface
The Spec File to build the Adempiere RPM was developed and tested on Fedora 13.
The Fedora Packaging Guidelines have been followed, with some exceptions:
- Version and Release Numbering
- Pre-built Binaries and Libraries
- Spec File Legibility
- Tags
- Requirements
- Documentation
- Users and Groups
Version information should be in the form:
majorVersion.minorVersion-buildNumber.patchNumber.releaseTag
So if upstream releases its product as adempiere351a, it should be packaged as:
adempiere-3.5-1.X.a
(where 1 is the build number and X is the packager's "patch level", which is incremented on each build).
However, upstream maintains the build number as part of the version number, and it does not follow the convention of 0=pre-release, 1=release, >1=post-release. For RPM's version control method, it therefore makes more sense to use the revision in the Mercurial repository as build number.
We also want to have automatic patch-level numbering, and the build date seems most suitable for that purpose.
Therefore, our version numbering will have following syntax:
majorVersion.minorVersion.buildNumber-hgRevision.buildDate.releaseTag
which would result in following package names:
adempiere331 -> adempiere-3.3.1-1943.buildDate adempiere354a -> adempiere-3.5.4-5276.buildDate.a adempiere360lts -> adempiere-3.6.0-6510.buildDate.lts
All binaries and libraries in Fedora packages must be built from source code. The source package is not allowed to contain pre-built binaries and libraries.
However, Adempiere comes with various *.jar archives containing pre-built *.class files.
Some of them are simply used as tools in the build-chain and would easily be replaceable with open-source Fedora libraries.
Others are used in the final product such as the jdbc-drivers for database connections. They would be more difficult to replace, although it would certainly be possible.
Since we are going to build Adempiere packages for our own use and not for distribution with Fedora, we will gracefully ignore this requirement for the time being.
All efforts have been made to keep the Spec File legible, whereby priority has been given to legibility in terms of humanly readable over being able to read and understand the algorithms.
Normally the user would only have to set or modify parameters at the beginning of the file
(marked “SETTINGS”), add his sources and patches to the preamble (marked
“your custom sources come here” and “your custom patches come here”),
and install or apply them in the %prep section (marked “install your sources here” and
“apply your patches here”). Everything else should just work.
Many different parameters can be used in the Spec File, and commenting them all in place would result in a very long settings section where important or conflicting parameters could easily be overlooked. Instead, the parameters are explained with their default values in the appendix of this manual. All parameters have sensible default values, so even if no parameters are set the Spec File will still produce an installable and runnable package.
Macros used by the build and installation scripts are defined and evaluated in a section titled “INITIALIZATION”, which comes between the settings and the preamble. Inside the scripts, the function and contents of those macros can be understood intuitively by their names, and as most people will not want to get into the detailed algorithms of how they were defined, the definitions are written in a way that keeps the Spec File nice and tidy and easily readable by humans. For debugging purposes, it is recommendable to expand those macros to multiple lines where necessary for easier understanding of conditions, loops, etc.
A lot of regular expressions are used in combination with grep, sed, and awk in the macro definitions. They are not further explained, as commenting one line of code with twenty lines of explanation would make the Spec File difficult to read as a whole.
Since all sub packages use exactly the same installation scripts (behavior is tweaked for each sub package by just setting some variables at the beginning of the scripts), rather than writing the scripts again and again, they have been included as source files which will be dynamically expanded when the packages are built.
The SOURCES directory easily becomes very messy when numerous source files
and patches are scattered about. For this reason, the files distributed with the Source-RPM are prefixed
with sXXX_ (for sources) and pXXX_ (for patches), where XXX corresponds to the patch or source number
in the Spec File. Users are encouraged to name their sources and patches following the same scheme,
starting with number 100.
The Packager and Vendor tags are used in spite of the guideline's
recommendation not to do so. They are used for identification and documentation purposes to differentiate
between the original distribution and patched versions.
The BuildRoot tag is present for compatibility with other
RedHat-like systems.
Adempiere requires Java to run. As of Adempiere 3.6.0, JDK 1.6 is required.
Actually any Java distribution can be used, and the original Sun Java software is most tested and reliable for Adempiere. But since it is not distributed as an RPM, and theoretically can be installed at any location, it is virtually impossible to check for it as a build or target requirement.
Therefore the openJDK distribution is listed as requirement for both compiling the source and installing the RPM on a target machine. The user is still free to use any Java distribution he wants, but openJDK must at least be installed.
Adempiere mainly uses online documentation. Text files such as README in the source code are often meaningless. However, all pdf files found in the source after compiling are copied into the documentation folder for all sub packages, regardless in which sub package they were found and without distinguishing whether they are for users, administrators or developers.
If the adempiere user or group already exists on the target system, an attempt is made
to change the uid and gid to those defined in the Spec File, and to move the home directory to the
location defined in the Spec File.
