<h2>JDS RPM Rules</h2>

<style>

li {padding:3px;}

</style>

<p>

The following RPM rules apply for hacking on the JDS sources -

<p>

<h3>Scripts</h3>

<ul>

<li>

pre/post-install/remove scripts should never touch files belonging

to another package.

</li>

<li>

Never add or delete files in pre/post-install scripts. Adding files

will result in files in the file system that do not belong to any

packages. Removing files will cause the package to fail

verification (rpm --verify) and result in warnings about missing

files when you uninstall the package.

</li>

<li>

If you change a file in a pre/post-install script, make sure you

use

<a href="http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-CONFIG-DIRECTIVE">%verify</a>

directive to tell RPM not to verify the MD5 checksum, size and

modification of that file when running rpm --verify -

<blockquote>

<tt>%verify (not md5 size mtime) file.conf</tt>

</blockquote>

</li>

<li>

The script fragment for registering help docs with scrollkeeper

should be "<tt>scrollkeeper-update -q</tt>" and nothing else.

</li>

<li>

Do not use the "j" or "z" flags of tar to uncompress sources

as it's not portable on Solaris. Use

"<tt>bzip2 -dc %SOURCEn | tar xf -</tt>"

</li>

</ul>

<h3>Dependencies</h3>

<ul>

<li>

When <tt>%pre</tt> and <tt>%post</tt> scripts depend on other

packages (almost always the case), the package has to use

the <tt>PreReq: <i>other-package</i></tt> tag to define that

dependency. This tag ensures that other-package is installed

before the package that defines the tag. The Requires tag

only specifies that both packages need to be installed to

get a running system, but the order is not important.

<br/><br/>

For example, if <tt>%post</tt> calls <tt>scrollkeeper-update</tt>,

then the spec file must include "<tt>PreReq: scrollkeeper</tt>".

</li>

<li>

When a previously delivered package obsoleted by new one, and

therefore no longer delivered, the new package has to use the

"Obsoletes" tag to avoid problems with upgrades. If the new

package still provides the old code, also use the "Provides"

tag. For example, if package <tt>bonobo-activation</tt> is

merged into <tt>libbonobo</tt> put this into <tt>libbonobo.spec</tt> -

<pre>

%define bonobo_activation_version 2.4.0

Obsoletes: bonobo-activation < %{bonobo_activation_version}

Provides: bonobo-activation = %{bonobo_activation_version}

Obsoletes: bonobo-activation-devel < %{bonobo_activation_version}

Provides: bonobo-activation-devel = %{bonobo_activation_version}

</pre>

</li>

</ul>

<h3>Files</h3>

<ul>

<li>

Always use the most specific directory variable, e.g.

<tt>%_bindir</tt> instead of <tt>%_prefix/bin</tt> and

<tt>%_datadir</tt> instead of <tt>%_prefix/share</tt>.

</li>

<li>

Use the

<tt><a href="http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-CONFIG-DIRECTIVE">%config</a></tt>

directive for config files.

</li>

<li>

Do not include libtool's .la files in the packages. Not even in the

devel package.

</li>

<li>

Do not include static libs unless absolutely necessary, in that case,

include it in the devel package.

</li>

<li>

Include lib*.so.* in the base package, lib*.so in the -devel package.

</li>

</ul>

<h3>Patches</h3>

<ul>

<li>

All patches should be p1 (i.e. the files names in the diff start with the

top level source dir and you use <tt>%patchn -p1</tt> in the spec file.

</li>

<li>

The patch naming convention should be the following -

<tt>module_name-nn-descriptive_text.diff</tt>, where <tt><i>modules_name</i></tt>

is the base name of the spec file without the .spec, <tt><i>nn</i></tt> is the

number of the patch (<tt><i>Patchnn</i></tt> tag in the spec file) and

<tt><i>descriptive_text</i></tt> is a very short description of what the patch

does or why it is needed, e.g.:

<blockquote><tt>

gst-02-fix-registry-crashes.diff.

</tt><blockquote>

</li>

<li>

When you remove a patch, make sure that patches with higher numbers are renumbered

(update <tt><i>Patchnn</i></tt> tag in the spec file, rename file, cvs remove

old_file, cvs add new_file). There is a script in the <b>scripts</b> directory to

automatically reorder patches - use it carefully if you do so.

</li>

</ul>