Validating a package before you share it #

This page is for designers about to publish an .ezpkg. The receiving installation inspects every upload before writing anything; a package that fails there fails for your users. Check it first.

What an installation checks on upload #

1. The name ends in an allowed suffix (ezpkg, tar.gz, tgz) and the file starts with the gzip signature.
2. It is within MaxArchiveSize (256 MiB by default), MaxEntries (50,000) and MaxUnpackedSize (2 GiB).
3. Every entry is a plain file or directory with a relative path: no .., no absolute path, no back slash, no control character, no link, no device.
4. A well-formed package.xml (or package.json) is at the top, with <package> as root, a valid name, version and packaging information, and a vendor that gives a repository name.
5. No package of that name exists in any repository yet.

Then each document must be well formed and, for a JSON package, match the schema and its checksums.

Step by step #

1. On your development installation, open the package's page and press Validate. It shows what was checked or every problem.

2. On the command line, validate the exported file itself:

   php ezpm.php validate var/tmp/mytheme_classes-1.0.0-1.ezpkg

3. Look inside:

   tar tzvf var/tmp/mytheme_classes-1.0.0-1.ezpkg | head -30

   Every path is relative and below the package; no l (link) entries in the first column.

4. Extract the definition and check it:

   mkdir -p var/tmp/pkgcheck && tar xzf var/tmp/mytheme_classes-1.0.0-1.ezpkg -C var/tmp/pkgcheck
   xmllint --noout var/tmp/pkgcheck/package.xml

   Expected: no output from xmllint.

5. Import it into a throwaway installation (Installing your package on a test site).

When validation fails #

Related pages #

• Packages, section 6: uploading
• Classic XML and JSON packages
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.