[doap-interest] wherefore art though, dependencies?
Robert Collins
robertc at robertcollins.net
Tue Sep 1 00:38:09 CEST 2009
So, I see that project dependencies are still a TODO?
Edd, you've said you want to clone Debians facilities into DOAP. I think
this would be a mistake: Debians build and runtime dependencies serve
three different masters, only one of which is relevant for a given
project.
I think its a great idea to be inspired from Debian's facilities, and to
permit Debian package metadata to start inheriting the upstream
dependencies from DOAP descriptions.
The three masters are:
* Upstream requirements. 'I need a C compiler to build, I work with any
python > 2.3, I need an implementation of ISCM, I need an MTA'
* Debian specific issues/translations of the above:
- Deals with Epochs
- Deals with library ABI bumps (that upstream may not have done or
even be aware of - e.g. historically just changing the C++ compiler
on the distro has caused this)
- Deals with different names 'On Debian ISCM is known as IFooBar'
- Deals with Debians split-out of a package. Building a package
generates many individual artifacts; Debian has very specific
policies about how these should be placed on disk *and grouped*
into downloadable .deb files. For instance, as an upstream I
might not separate header files/static libraries and shared
libraries. Debian will however separate them into different
named debs, and thus the dependencies for a package that needs
the headers are named accordingly.
* Debian packaging requirements:
- This package must be unpacked on disk before this other package
- Remove some 3rd package before building this package because we
choose not to support some autodetected option
- Installing this new release of the package breaks the shared
library of the prior binary package.
From an upstream perspective, I want my DOAP files to be simple and
unambiguous. If I'm using library FOO, its sufficient to say I'm using
it, not that I require its header files to build.
I'd like declaring dependencies to be something around about as simple
as:
<Project...
<dependency>
<Project rdf:about="http://python.org">
<name>Python</name>
</Project>
</dependency>
</Project>
"my project depends on python."
The debian dependency system is also a bit less than ideal due to having
grown. Specifically things that should be orthogonal are squashed into
the same dimenson. IMNSHO, YMMV, etc.
http://www.debian.org/doc/debian-policy/ch-relationships.html
Some sort of algebra will be needed to represent dependencies on 'A and
B' - this usually shows up for optional features.
So, define a group of projects somehow, with version relations within
the group: << <= == >= >> !=
Then,
A Project Foo->ProjectGroup Bar dependency-relationship has:
A time:
* build
* test
* run
* supply
It has an presence:
* Must
* Should
* Could
* Cannot
Together we get:
'To ${time} Foo correctly, ${Bar} ${presence} be present.'
Supply may not be obvious - Its there for Enhances. E.g. 'To supply
vimperator correctly, firefox should be present'
-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.usefulinc.com/pipermail/doap-interest/attachments/20090901/27fc5d8c/attachment.pgp
More information about the doap-interest
mailing list