<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>