RE: [Caml-list] LablGtk3 beta1

[David Allsopp <dra-news@metastack.com>]

Emilio Jesús Gallego Arias <e@x80.org> wrote:
> 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.

Please let's not have another file format in opam :-/

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

The current model can, inasmuch as you can create a dummy package whose purpose is to express what ">= 3.18" actually means for each individual packager. You can imagine that if you were talking about the Linux kernel, you may well have > 4.xx.yy for a stock kernel but a special case of > 3.10.x for RHEL, because the thing you want is backported (obviously a slightly banal example, because you'd never determine a kernel feature by version number, but hopefully it serves the point - there are other libraries where you might).

The current model can deal with packages A and B neatly, yes - what's not neat is that two separate packages get installed (conf-at-least-gtk-3-18 and conf-at-least-3-20). The build instructions for those two conf packages would include Debian-specific strings to test for the -x part. It's definitely not a perfect solution, but your proposal of versioned depexts I think simply moves the trade-off to be considerable complexity in the depext code from having a relatively small number of these dummy packages.

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

I'm sorry, I'm still not following the comparison here. Having 1 conf- package for each depext sounds entirely correct, in terms of the "database" of OS-specific package names for that depext.

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

Indeed - but the user experience is entirely correct to say "we can't install conf-gtk3 because you don't have the system libraries for it". It would then be correct to say "we can't install conf-at-least-gtk-3-18 because you have GTK3 < 3.18".

Not likely for gtk3, but imagine you were installing lablgtk3, marialablgtk3, librelablgtk3 and lablgtk3Org all of which, despite disagreeing with Jacques on how lablgtk3 should run as a project, all definitely agree that they depend on the underlying GTK3 binaries - the conf-gtk3 package gives a much better user experience if the GTK3 package is < 3.18 because it's the single failure, as opposed to all of them failing individually.

The conf-at-least-gtk-3-18 package would be able to display a very clear opam error message explaining the problem as the only error which can occur is that. 

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

So provide the two packages in separate opam repositories? Yeouch. The user experience for the -conf version is capable of being slightly clearer, inasmuch as on a build error you can be reasonably sure that the error is the lack of GTK3, whereas a build error in lablgtk3 could be other things - opam's own error messages (in post-messages) are much clearer to consume than trying to read the build output, which is all you'd have in the other case.

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

If there are 8 distinct depexts, then there should be 8 distinct conf- packages - I'm sorry if your library is complicated :o)

But look on the other side - these conf packages are only normally updated to include package names missing for other distributions - in other words, other contributors quietly improving them. It seems to be me that you're anticipating a maintenance burden which won't exist here, and doesn't exist for the conf- packages already in opam-repository.

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

This is almost entirely separate - at present, Dune doesn't care about conf- packages, and you don't need to specify them. Dune also has no knowledge of depext, so even in a multi-project tree you're still responsible for ensuring that your system libraries are present, not Dune. The work going on in Dune to be able to generate opam files automatically is already aware of the need to support them.


David

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