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

[Stefano Zacchiroli <zack@upsilon.cc>]

On Fri, Feb 01, 2008 at 04:03:42PM +0100, Gerd Stolpmann wrote:
> > 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:

Fair enough. Socially however, I doubt you will be able to seek several
opinions in this sub-sub-sub thread :), you should probably start a new
thread or something such.

I will answer for myself.

> - Are software maintainers willing to provide the information in a
>   formalized way? That would mean they had to understand the details

Wearing my hat of (not so widespread) software maintainer, it wouldn't
make any difference. If I care about proper installation instruction I
already have to maintainer a proper INSTALL file, maintaining a more
formal dependency expression in a file won't be much of a difference.
Actually, if the format spreads and the community reach an agreement on
it, it would be even better since I can avoid writing useless prose to
describe the deps in INSTALL, and just care of the dependency
expression.

(Note that in my case, since I'm also the Debian maintainer of my
software, I'm also already maintaining the dependency expression, but I
presume this is not a common case.)

> - 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.

In general, the usefulness for the users depends on the available tools
using the dependency formalization. This is a like a chicken and egg
problem: until we have the formalization we won't be able to show
usefulness. I'm trying to catch the bus which is passing: if we are
going to formalize software installation related stuff, I'll try to get
it right without loosing information.

Anyhow, regarding your end users point, I don't know for GODI since I'm
not using it, but in Debian we have always kept in mind that users
should be able to install OCaml libraries which are not packaged in
Debian. So, for example, our default findlib configuration supports
/usr/local/... The reason is that no packaging framework supports every
piece of OCaml software out there.  In this sense, end users do install
software, and a dependency formalization would give us possibilities
such as:

- have a single system (ocamlfind based) to check if the required deps
  to compile a library or program are available

In a word, it would get us nearer to CPAN's "perl Makefile.PL" 1-click
installation procedure.

> _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?"

Full ACK: the simpler, the better. Something like that is fine with me,
though I would like to see at least >= version checking. See below ...

> 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.

I'm less convinced about that (though we are getting into details here,
whereas your bold "If" above is still to be settled). It is true that
there are various syntaxes for versions, but they do entail different
comparison results only in very corner cases. Take pkg-config, AFAIK it
supports >= version comparisons supporting just one syntax for versions.
It does work fine with 99.9999% of the software libraries out there.

> 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.

Agreed, also it is seldomly needed.

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