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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Donnerstag, den 31.01.2008, 10:02 +0100 schrieb Stefano Zacchiroli:
> 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.

Interesting view, but it still doesn't convince me that including a
formalization of deps would be worth the effort. I would like to hear
more opinions about this:

- Are software maintainers willing to provide the information in a
  formalized way? That would mean they had to understand the details
  of the formalization, and also had to maintain these data (e.g.
  respond to users who find errors etc.). Depending on how much detail
  the formalization can express, this can be very easy or tricky.

- Is this so useful for the users that they really need it? I mean
  the primary users would be the existing distribution systems
  like GODI or Debian that already have formalizations for deps. 
  I expect that most end users won't directly install software,
  and if so, it is likely that they run manually through the
  the build package by package, so a description of deps in English
  would be almost as useful as a formalization.
  
_If_ we agree that a formalization is useful, I am still of the opinion
the simpler the better. So maybe only a list of build requirements,
where some are flagged as optional. That would be a simple string

"pgk1 pkg2 pkg3? pkg4?"

(where "?" signals an optional dependency).

Including version requirements has the disadvantage that it enforces a
certain syntax of the package names, and that there are several
solutions for comparing version strings.

For even more structure like alternatives, or mutual incompatibilities I
don't see how this could be processed in a uniform way. The package
systems are very different in this point.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------