(→BuildRoot tag) |
(→Writing a package from scratch) |
||
| Line 160: | Line 160: | ||
== Writing a package from scratch == | == Writing a package from scratch == | ||
| - | See Spectacle | + | See [[Spectacle]] |
| - | + | ||
== Modifying existing Packages == | == Modifying existing Packages == | ||
Contents |
Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.
The Version field in the spec file is where you should put the current version of the software being packaged. There are four cases where the version contains non-numeric characters:
This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.
There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.
The release number is set to zero with any version update. It is increased by one with any change in the package.
%packager in your ~/.rpmmacros instead.
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.
It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.
The RPM spec file contains only the English version to keep the RPM database small.
Valid RPM Groups are:
Amusements/Games Amusements/Graphics Applications/Archiving Applications/Communications Applications/Databases Applications/Editors Applications/Emulators Applications/Engineering Applications/File Applications/Internet Applications/Multimedia Applications/Productivity Applications/Publishing Applications/System Applications/Text Development/Debuggers Development/Languages Development/Libraries Development/System Development/Tools Documentation System/Boot System/Console System/I18n/Chinese System/I18n/Japanese System/I18n/Korean System/Packages System/Base System/Daemons System/Kernel System/Libraries System/Shells System/X11 System/X11/Fonts System/X11/Icons System/GUI/XFCE System/GUI/Other System/GUI/GNOME
The BuildRoot value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}.
The recommended values for the BuildRoot tag are (in descending order of preference) :
%{_tmppath}/%{name}-%{version}-%{release}-root
The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.
Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.
Packages must not contain explicit Requires on libraries except when absolutely necessary. When explicit library Requires are necessary, there should be a spec file comment justifying it.
We generally rely on rpmbuild to automatically add dependencies on library SONAMEs. Modern package management tools are capable of resolving such dependencies to determine the required packages. Explicit dependencies on specific package names may aid the inexperienced user, who attempts at installing RPM packages manually, however, history has shown that such dependencies add confusion when library/files are moved from one package to another, when packages get renamed, when one out of multiple alternative packages would suffice, and when versioned explicit dependencies become out-of-date and inaccurate. Additionally, in some cases, old explicit dependencies on package names require unnecessary updates/rebuilds.
Exemplary rationale for a versioned explicit dependency:
# The automatic dependency on libfubar.so.1 is insufficient, # as we strictly need at least the release that fixes two segfaults. Requires: libfubar >= 0:1.2.3-7
Packagers should revisit an explicit dependency as appropriate to avoid it becoming inaccurate and superfluous.
In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its configure script detects that libpng is not installed.
Before adding BuildRequires to any package, please be comfortable with Requires .
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:
The name of a patch file consists of:
.patch
Patches are in the unified format (diff -u) and should be applied with 1 strip level in the spec file (%patch -p1). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.
Each patch should be compressed with bzip2 if its size is greater than 100kB. The macros %name and %version should be used whenever possible.
Example:
Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch
For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as
%setup -q %patch0 -p1 %patch1 -p1
See Spectacle
If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.
In particular, you should
Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.
This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)
Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in chronological order. Newer change log entries are listed above older entries, with the first entry being the most recent.
Tue Apr 22 20:54:26 CEST 2009 - your@email.com -
In short, the changes file is identical in format and purpose to debian's changes file.
During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Adding an entry with bugzilla number to the changelog should result in a short description of the bug-summary and the bug number. For example:
- Removed invalid desktop Category "Application" (MB#4654). - Symlink icon to pixmaps dir (MB#2108) - Added gnome-ui-properties to control-center (MB#1960).
Same as for bugzilla numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (MB#226710, and CVE-2007-0010). - More XPM fixes: CVE-2005-2975 xpm too many colors DoS (MB#129642) - fix ~/.dmrc symlink attack (MB#180704, CVE-2006-2449)
Be as precise as possible! This is especially important if you remove something from the spec file.
Document the most important changes but limit verbosity.
- Update to 1.3.2: + fixes memory leak in import function + new API command: unlock_client() + the following bugs are closed by this new upstream release: ++ ............ [MGN:332] ++ .............[MGN:337] - split of devel package