CHAPTER 15 ■ AN INTRODUCTION TO PEAR AND PYRUS
Although this is mostly self-explanatory, it’s worth pointing out a couple of features. Of the elements
inside version, release is the one that really counts as far as your package is concerned. The release
element is used by PEAR in dependency calculations. If another system claims to require Dialekt 1.0.0,
and the installing user only has version 0.2.1 on her system, PEAR will halt its installation or attempt to
fetch a later version, depending on the mode in which it was run. The api element, on the other hand, is
there so that you can keep track of changes in your code’s interface which may affect compatibility.
The stability element is similarly split between release and api. The value can be one of snapshot,
devel, alpha, beta, or stable; you should choose the one that best describes your project.
If you are releasing your package according to specific license terms (such as GNU’s GPL license, for
example) you should add this information to the license element.
Unlike summary and description, the notes element will accept line breaks in the contents you add.
The contents Element
Now, we’re finally ready to talk about the files and directories in the package. The contents element
defines the files that will be included in the package archive (sometimes called a tarball, because it’s
archived with the tar and Gzip tools). You can describe the structure of your archive by combining dir
and file elements.
Here’s a simplified example:
Every file in a PEAR package has a role. Every role is associated with a default (configurable)
location. Table 15–2 describes the common roles.
Table 15–2. Some Common PEAR File Roles
Role Description PEAR Config Name Example Locationphp PHP file php_dir /usr/local/lib/phptest Unit test file test_dir /usr/local/lib/php/test/<package>
script Command line script bin_dir /usr/local/bindata Resource file data_dir /usr/local/lib/php/data/<package>doc Documentation file doc_dir /usr/local/lib/php/doc/<package>