Re: [Caml-list] LablGtk3 beta1

["Emilio Jesús Gallego Arias" <e@x80.org>]

Louis Gesbert <louis.gesbert@ocamlpro.com> writes:

> I don't believe that's what was suggested in the original message,
> though ? The pointed issue seemed to me that we don't handle detailed
> versions for `conf-*` packages, which means we can't encode precise
> dependencies to the underlying system package versions. In other
> words, _handling_ the fact that "package A requires version > 2.10 and
> package B version > 2.11" is no problem at all for opam, but
> _expressing_ it is, for `conf-*` packages.

Exactly, thanks for the summary Louis.

> The thing is that we can only detect the installed versions of system
> packages, not control them (even with `opam-depext`, we can trigger
> the installation of a given package, but most distributions don't
> allow to choose between multiple versions). In this case, you will
> have to rely on your package's `./configure` to fail when the version
> of the system dependency doesn't match, which is not the most helpful
> solution; adding the depexts to the package directly could help a bit,
> but again, as we don't control the system package version anyway, not
> that much.
>
> There is one way we could improve a (little) bit:
> e.g. `conf-gtksourceview` could expose¹ a `system-version` variable
> upon installation, e.g. `2.11`, and then you could fail explicitely
> with a message directly from the opam file, without relying on
> `./configure` (it will still fail only at build time, though, because
> the value of the variable can't be known yet at resolution time).

I am still not convinced by this; it seems to require quite a bit of
overhead for something that is IMO better done on the package itself.

The thing is that packages are the ones that really know what they
depend upon; adding this indirection layer serves little purpose.

Something that should be very useful tho is to be able to rely on a
centralized depexp database.

Thus, when I write "depext: [ gtk-2.0 >= 2.11 ]" I don't have to provide
the info for native mappings, and I can check what the supported set of
names is, etc...

Best,
E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs