[doap-interest] wherefore art though, dependencies?

[Robert Collins]

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