standard dependancy system
talex5 at gmail.com
Fri Nov 23 04:56:03 PST 2007
On 23/11/2007, Patryk Zawadzki <patrys at pld-linux.org> wrote:
> 2007/11/23, Stanislav Brabec <sbrabec at suse.cz>:
> > 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://repo.or.cz/0release.git
$ cat 0release/0release.xml
<group license="OSI Approved :: GNU Lesser General Public License
(LGPL)" main="0release" self-test="tests/testrelease.py">
<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/testrelease.py'.
- 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
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
> > - "Packaging paradigm" (each vendor can define their own description,
> > how to call "./configure ; make ; make install").
> > - 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 configure.ac 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 http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
More information about the xdg