This is my README for using .rph files:
---------------------------------------

The the disk description files (.txt files) will be phased out in
version 2 of the Install program in favor of package info files (.rph
files, or Red Hat Package Header file).  The ".rph" was chosen because
the package info file is truly the header to a Red Hat RPM.

I know it sounds silly to make such a big deal over a file's
extension, but I intend to continue using the package info files at
least through version 4 (that's as far ahead as I'm thinking now.)  I
wanted something that was clear for the programmer to understand,
since the programmer (or software distributor) is the one who will
most likely be writing the package info files.  General users of the
Install program, users who don't do any programming, probably don't
care what the extension is.

The .txt files contained the descriptions of each of the packages on
an install disk.  For example, an example BASE.TXT file might have
contained entries like this:

  asgn14x: Steffen Kaiser's ASSIGN program, version 1.4.  Allows you to
  asgn14x: assign one drive letter to a different drive.
  attr-x: The ATTRIB program, to view and set file attributes.
  b1932-x: Pat Villani's DOS-C kernel (the FreeDOS Kernel.)  This is
  b1932-x: beta code, but Pat says it is okay to distribute anyway.  It
  b1932-x: is more stable than any previous DOS-C kernel.
  b1932-x: THIS DOES NOT AUTOMATICALLY INSTALL THE DOS-C KERNEL AS YOUR
  b1932-x: DEFAULT OS.  YOU WILL NEED TO RUN THE BAT FILE IN THE KERNEL
  b1932-x: DIRECTORY TO CREATE A BOOTABLE DOS-C FLOPPY.
  bwbas-x: Ted Campbell's ByWater BASIC interpreter.

Each disk in the BASE series had a BASE.TXT file that contained
descriptions of each of the packages on that disk.  This made things
easier on the Install program - but if you wanted to download all of
the BASE disks into a single directory, the BASE.TXT files would have
a name conflict.  When you downloaded the BASE.TXT file from BASE-2,
you overwrote the BASE.TXT file from BASE-1.

Eliminating name conflict was one reason I wanted to migrate away from
disk description files.  I also wanted to preserve the information
about a package.  For example, if I wanted to find out the copyright
on Bywater BASIC, I needed to (1) download the whole package, (2)
unzip it, and (3) read the README.

My answer, I decided, was to create a package info file that would go
hand-in-hand with the package file itself.  Along with the
INST121X.ZIP package, for example, you would also have an INST121X.RPH
file.  The .rph file is the package info file.  The package info file
contains everything that you need to know about a package: a
description of the package, the version, where to get updates, its
copyright.

I tried to implement my own package info file format from scratch.  I
posted some comments on that a while back.  (Thanks to everyone for
some useful advice on what needed to appear in the .rph file.)  Then I
realized that I was re-inventing the wheel: Red Hat Software already
had created an RPM file - Red Hat Package Manager.

The Red Hat Package Header files are the same as the header on an RPM
file (no surprise there.)  Those of you who have worked with RPM files
(especially if you've built RPMs) will find the .rph file format very
familiar.  The README for a .rph file library I've started can be
found at ftp://ftp.isd.net/jhall1/freedos/rphfiles.txt, but basically
this is what a .rph file contains:

  Name: _____________
  Version: ______
  Release: __
  Summary: _____________________________ \
  _______________________________________ \
  ___________________
  Icon: ________
  Source: ____________________________
  Patch: ___________________________
  Copyright: _____________
  Root: ______________
  Group: _______________________
  %description
  _____________________________________________
  __________________________________________
  ____________________________________________
  _____________


I have extracted Red Hat Software's description of the RPM header,
which you can view in 'rph.html'.  You can get more information about
a Red Hat RPM header from this page:

  http://www.rpm.org/support/RPM-HOWTO-6.html#ss6.3


Most of the fields are pretty obvious.  You all should know that the
Summary: and Version: fields represent.  A few that you may not know
are:

  - 'Name:' is preserved in .rph files so that you can easily create
  RPM files from your .rph file.  This field is not used in the
  FreeDOS Install program.  (RPM files don't care what the filename is
  - the 'Name:', 'Version:' and 'Release:' fields are used to track
  the "real" name of an RPM file.  RPM filenames are usually something
  like "dosemu-0.66.7-7.i386.rpm" where "dosemu-0.66.7-7" is the real
  name.)

  - 'Release:' is the release number of your package.  For example, if
  you are creating your own distribution, and you first make a fix to
  DOS-C, then 'Release:' would be '2'.  Usually, 'Release:' will be
  '1', because I don't make patches to other people's programs when I
  create the FreeDOS distribution.  I just don't have the time.

  - 'Icon:' would be used for a high-level installer.  I do not plan
  to use this.

  - 'Root:' is where you specify a root path for the package.  I will
  not use this in 2.0, but I may add support in 2.1 or later.

  - 'Group:' would also be used by a high-level installer to place
  this package in an install tree.  I don't use this field in the
  FreeDOS Install program.  I use the DAT files instead.

The '%description' tag is not technically part of the Red Hat Package
Header, but an rph file should always have one anyway.  Red Hat
Software recommends that all RPM headers have a '%description'
attached to it.

I have also added an 'Author:' field, although the name may change
before I release version 2 of the Install program.

The only field that will be used in version 2 of the Install program
is the %'description' field, to contain a description of the package.
Note that this spans several lines, and is terminated either by EOF or
a blank line.

At least for version 2, the other fields will only exist to track
important information about a package.

I will treat the field names as case-sensitive.
