standard dependancy system

Thomas Leonard talex5 at
Fri Nov 23 04:56:03 PST 2007

On 23/11/2007, Patryk Zawadzki <patrys at> wrote:
> 2007/11/23, Stanislav Brabec <sbrabec at>:
> > Preparing thousands of packages, I am often thinking about a generic
> > package description as well.
> >
> > I can imagine such standard dependency system one level lower: In the
> > package source level.

This is exactly what we do already. If you checkout almost any ROX or
Zero Install application, you'll find a metadata XML file listing its
dependencies and other information. e.g.

$ git-clone git://
$ cat 0release/0release.xml
  <group license="OSI Approved :: GNU Lesser General Public License
(LGPL)" main="0release" self-test="tests/">
    <requires interface="">
      <version not-before="0.13"/>
      <environment insert="0publish" mode="replace" name="0PUBLISH"/>
    <implementation id="." version="0.4-post"/>

This tells you that:

- This program (0release) is released under the LGPL.
- You can run it using the '0release' executable at the top-level.
- You can run the unit-tests by running 'tests/'.
- It requires the 0publish program, version >= 0.13.
- This is a developer snapshot, after version 0.4,

> All valid points but software is only maintained for as long as it's
> fun to do so. Adding additional requirements to software vendors is
> not the best approach until we give them tools to automatically check
> and prepare such info.

For preparation, there is a nice GTK UI here:

For checking, there isn't too much of a problem, because the
dependency descriptions are always used to find libraries at run-time.
If the developer forgets a dependency, they can't run their own
program ;-)

To check the URLs still resolve (for packages not available in
distributions), you can use FeedLint:

> > The description shoud say us:
> > - URLs of home pages of dependent packages.

The XML format is specified here:

> > - Description of optional dependencies and optional features.

Optional dependencies are still a TODO item, although they're not
usually required if you have an always-on network connection because
you can just install extras as you need them.

> > - Description of pre/post install scripts and other special actions
> >   needed.
> > - Propose package splitting.

It's probably easiest to just split in all cases where the developer
thinks it might be useful. You can always combine split-up packages
into a single bundle if required (e.g. to transport to a non-networked
machine). e.g.

> > - "Packaging paradigm" (each vendor can define their own description,
> >   how to call "./configure ; make ; make install").

Sure. See:

> > - And yes, optional information can be provided.
> >
> > It could be a huge help for packaging automation.

Exactly. It also makes it easier for upstream to create releases if
all this information is specified. e.g.

> > I see that for example already contain some of these
> > information, but in a form, which is machine executable, but machine can
> > not parse and understand it. You can do post-mortem analysis of
> > config.log and try to guess, what was really needed.

Right. This is why we use XML.

Dr Thomas Leonard
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

More information about the xdg mailing list