Re: [Caml-list] LablGtk3 beta1

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

David Allsopp <dra-news@metastack.com> writes:

> You were advocating putting the depext information (as required at the
> moment - with lots of os-specific package names) on the lablgtk3
> package. n in my case is every package which also wants to depend on
> the GTK3 library, which would have to duplicate that same depext
> information. Granted, at the moment n = 1, but that's not really the
> point.

Ah, indeed sorry I was not clear; indeed what I was thinking is about a
model where the os-dependent information is centralized, but not by
using a package, but a proper database of mappings / recipes.

So indeed maybe the core question is whether using "dummy" package for
capturing this is the best abstraction.

> Even if you carve the OS-specific package names off somewhere else,
> "gtk3 >= 3.18" is not guaranteed to be how you'd express that on all
> platforms, so that notion also probably needs to be centralised too
> (one word: backports).

Indeed that's a problem; I would say that OPAM could talk about upstream
version, but in some cases that may not be enough. But this is something
the current model cannot do very accurately either, right?

[Like if for example two packages A, B depend on gtk where A needs GTK >=
 3.18-4 and B needs 3.20-2 where -x is the Debian version]

> No - depexts are not part of the dependency tree for the solver,
> they're metadata for a package which has already been selected by the
> solver - that's why version constraints on them are harder to achieve,
> because the packages have already been selected.

I meant that depexts are not, however the `conf- package is. So if we
need 1 conf- package for each depext that doesn't seem to be a huge
improvement right?

> Well, it's so much caring, as being able to! It's just not that the
> conf- packages are not working well - they're doing exactly what
> they're supposed to, they just can't do what you'd like them
> additionally to do.

Sure, I was being concerned for user experience with `conf-gtk` where
the package can be installed but the bounds are not the right ones.

>> If I understand correctly then, as of today I could provide 2 lablgtk opam
>> packages, one depending on conf-gtk3, and one not depending on it, and the
>> user would actually have the same experience in the case of an incorrect
>> gtk version, right?
>
> No - unless you mean that the two lablgtk packages would have
> different names? One of them must fundamentally have a higher version
> number than the other, and the one which depends on conf-gtk3 is
> always going to attempt to install it - opam won't magically fall back
> to the other one.

Sorry for the bad explanation. I meant to provide them "in parallel",
like I could package lablgtk in this way or in that other way. Both of
them would fail in the same way.

> Indeed - although IIRC it doesn't affect any other conf- packages, at
> least yet. So can we conclude that having two conf- packages for now
> is superior to leaving all that information permanently embedded just
> in lablgtk3?

I am still not sure the release workflow is superior: we'd have to
introduce 8 additional conf- packages, and we'd have to maintain the
OS-dependent info in the repos anyways.

> Nothing prevents the maintainer of lablgtk3 also being the maintainer
> of conf-gtk3 and conf-at-least-gtk3-18 (or whatever). If one chooses
> just to maintain lablgtk3 and depend on conf-gtk3 then the
> installability of that is the concern of opam-repository maintainers -
> that's what we have CI for. Someone else who proposes a change to
> conf-gtk3 which breaks lablgtk3 would be unable to get their PR merged
> without in some way fixing lablgtk3. You seem happy that the ocamlfind
> package is maintained by someone else. I mention it because the opam
> package for ocamlfind is not (and I don't think ever has) been
> maintained by ocamlfind's author...

I am trying to move all the OCaml software I work on to Dune +
dune-release, thus in the future indeed packages will be maintained
in-tree [by however takes care of the build system]

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