6550N/AThe following RPM rules apply for hacking on the JDS sources -
6550N/A will result in files in the file system that do not belong to any
6550N/A packages. Removing files will cause the package to fail
6550N/A verification (rpm --verify) and result in warnings about missing
6550N/A files when you uninstall the package.
6550N/A directive to tell RPM not to verify the MD5 checksum, size and
6550N/A modification of that file when running rpm --verify -
6550N/A The script fragment for registering help docs with scrollkeeper
6550N/A should be "<
tt>scrollkeeper-update -q</
tt>" and nothing else.
6550N/A Do not use the "j" or "z" flags of tar to uncompress sources
6550N/A as it's not portable on Solaris. Use
6550N/A "<
tt>bzip2 -dc %SOURCEn | tar xf -</
tt>"
6550N/A When <
tt>%pre</
tt> and <
tt>%post</
tt> scripts depend on other
6550N/A packages (almost always the case), the package has to use
6550N/A the <
tt>PreReq: <
i>other-package</
i></
tt> tag to define that
6550N/A dependency. This tag ensures that other-package is installed
6550N/A before the package that defines the tag. The Requires tag
6550N/A only specifies that both packages need to be installed to
6550N/A get a running system, but the order is not important.
6550N/A For example, if <
tt>%post</
tt> calls <
tt>scrollkeeper-update</
tt>,
6550N/A then the spec file must include "<
tt>PreReq: scrollkeeper</
tt>".
6550N/A When a previously delivered package obsoleted by new one, and
6550N/A therefore no longer delivered, the new package has to use the
6550N/A "Obsoletes" tag to avoid problems with upgrades. If the new
6550N/A package still provides the old code, also use the "Provides"
6550N/A tag. For example, if package <
tt>bonobo-activation</
tt> is
6550N/A %define bonobo_activation_version 2.4.0<
br/>
6550N/A Obsoletes: bonobo-activation < %{
bonobo_activation_version}<br/>
6550N/A Provides: bonobo-activation = %{bonobo_activation_version}<
br/>
6550N/A Obsoletes: bonobo-activation-devel < %{
bonobo_activation_version}<br/>
6550N/A Provides: bonobo-activation-devel = %{bonobo_activation_version}<
br/>
6550N/A Always use the most specific directory variable,
e.g. 6550N/A directive for config files.
6550N/A Do not include libtool's .la files in the packages. Not even in the
6550N/A Do not include static libs unless absolutely necessary, in that case,
6550N/A include it in the devel package.
6550N/A Include lib*.so.* in the base package, lib*.so in the -devel package.
6550N/A All patches should be p1 (
i.e. the files names in the diff start with the
6550N/A top level source dir and you use <
tt>%patchn -p1</
tt> in the spec file.
6550N/A The patch naming convention should be the following -
6550N/A is the base name of the spec file without the .spec, <
tt><
i>nn</
i></
tt> is the
6550N/A number of the patch (<
tt><
i>Patchnn</
i></
tt> tag in the spec file) and
6551N/A <
tt><
i>descriptive_text</
i></
tt> is a very short description of what the patch
6550N/A When you remove a patch, make sure that patches with higher numbers are renumbered
6550N/A (update <
tt><
i>Patchnn</
i></
tt> tag in the spec file, rename file, cvs remove
6550N/A old_file, cvs add new_file). There is a script in the <
b>scripts</
b> directory to
6550N/A automatically reorder patches - use it carefully if you do so.