Declaring dependencies #

This page is for developers who build a site package out of other packages: content classes, demo content, site styles, extensions. A site package installs almost nothing by itself; it names the packages that do the work, and the setup wizard fetches and installs them. A wrong or missing entry here is the most common reason a new site installs half-way. The general mechanism is on Dependencies and install order; this page is about what to write.

Contents #

1. The requires element
2. What the code does with it
3. Rules that follow from the code
4. What the shipped packages declare
5. The other dependency sections
6. Errors and what they mean
7. Checklist
8. Related pages

The requires element #

<dependencies>
  <provides />
  <requires>
    <require type="ezpackage" name="sevenx_classes" min-version="5.1" />
    <require type="ezpackage" name="sevenx_multisite_democontent" min-version="5.1" />
  </requires>
  <obsoletes />
  <conflicts />
</dependencies>

This is the <dependencies> of sevenx_multisite. eZPackage::parseDependencyTree() keeps every attribute of a <require> as it is.

What the code does with it #

1. Site type step (eZStepSiteTypes::downloadDependantPackages() in kernel/setup/steps/ezstep_site_types.php). For each <require> of the chosen site package: when no package of that name is imported, or the imported one is older than min-version, the old one is removed and the package is downloaded from the url of its entry in the same index.xml, then imported.
2. Kickstart (init() of the same step). For an already imported site package it checks every requirement against min-version and stays on the step while one is missing or too old.
3. Create sites step (kernel/setup/steps/ezstep_create_sites.php). In the order of <requires>, it fetches each required package; those with install_type="install" are installed, the others (site styles) are only read, for example for the site style's CSS files.
4. Install (eZPackage::installUnaudited()). Installing a package installs its own required packages first, when they are present in the repository.
5. The package page shows "Requires", with >= and the min-version and "missing" for a package that is not there, and "Required by" from the other packages' lists (kernel/classes/ezpackagecatalog.php).

Rules that follow from the code #

List every package directly. Step 1 downloads only the requirements of the chosen site package, not the requirements of those requirements. A package the site needs reaches the installation only if the site package names it, or if it was imported before.

Order is install order. Step 3 installs in the order written. Put the content classes before the content that uses them, and extensions before content that needs their datatypes.

Every requirement must be on the same package server. A requirement that is not imported and has no entry in the index.xml the wizard read cannot be downloaded ("the URL is unknown").

Write min-version in the form the required package uses. A min-version higher than the version the package really has makes the wizard remove and download it again on every run, and stalls a kickstart. Because the shipped packages use releases like 15-stable, a min-version="6.0" is not met by them; see Version numbers.

What the shipped packages declare #

Checked in the source repositories on 2026-10-18. Only the five site packages have requirements; none of the packages they require has any.

All of them are in the 6.0.15 index.xml. cjw_multisite lives in its own source repository but requires sevenx_classes from the 7x one: requirements cross repositories freely as long as the index lists both.

The other dependency sections #

<provides>, <obsoletes> and <conflicts> are read and written in the same form. Neither the setup wizard nor the install acts on <obsoletes> or <conflicts>. <provides> is filled by the package creators (for example one ezcontentclass entry per class) and read by the package page to list the classes a package carries. The shipped site packages leave all three empty.

Errors and what they mean #

Checklist #

• To do: Every package the site needs is a <require type="ezpackage"> of the site package itself.
• To do: The order is classes and extensions first, then content, then site styles.
• To do: Every name is spelled exactly as that package's <name>.
• To do: Every min-version is met by the version the package really carries.
• To do: Every required package is in the same index.xml, with a working url.
• To do: A fresh install in a sandbox ends without EZSW-050 or EZSW-051.

Related pages #

• Documentation requirements for site packages
• Dependencies and install order
• Version numbers
• The index.xml format
• Testing in a sandbox
• Site packages: start here
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.