Re: [Caml-list] Re: [OSR] Ports-like package management system

[Stefano Zacchiroli <zack@debian.org>]

On Wed, Jan 30, 2008 at 04:12:15PM +0100, Gerd Stolpmann wrote:
> > Or where you talking about runtime/development time dependencies?
> 
> See, this question already demonstrates that dependencies are a not so
> easy concept. It is at least difficult to reach a common understanding
> what would have to be listed as dep and what not. We have dependencies
> that come into play at different times, and there are also conditional
> dependencies (i.e. you need this software only if you want to build this
> special feature). Then there is the question of how detailed the
> dependency relation is (versions, or about allowing to have only parts
> of software units as dependency).
> 
> A formalization of deps needs some complexity in order to be useful, but
> that makes a common understanding of them more difficult. I have some
> doubts that we find a balance here, so my advice to leave a formal
> description of deps out.

That it is trickier than listing a handful of make targets if out of
discussion. That it is *so* tricky that should not be addressed I
disagree with.

All the required information you mention above are already a part of the
build instruction of whatever program library you find out there. The
INSTALL (or whatever) file should list the set of libraries which are
required to build properly that library; if some of them are optional,
they should be flagged as such.  My question is: given that this kind of
information are already available, why shouldn't we refrain to describe
it with a common syntax which can help in understanding mechanically
interrelationships?

Note that I'm not requesting to actually mandate the *use* of this kind
of information in whatever build system, but only to use "morale
suasion" on library/program authors to write them down in a parseable
syntax.

Regarding the kind of relationships which can be described and how
(alternatives, version requirements), the major GNU/Linux distribution
families have a quite large subset of supported feature which are not so
tricky and are agreed upon.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time