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:
> 
> > My opinion is less humble - unnecessary duplication and having to
> > maintain the same info in n places vs in 1 place is not a trade-off!
> > :)
> 
> Sorry David I don't follow, but I don't see where the "n" copies gets
> introduced in the approach I propose, could you provide an example?

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.

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

> > I don't think there's (yet) a formally written down policy - but there
> > is the existence of those conf- packages (i.e. the chameleon principle
> > - "do it like everyone else seems to be doing") and the comments of
> > the maintainers expressing the desire for their use (and occasionally
> > editing packages themselves to do it...)
> 
> I am not sure I can declare myself a fan of the "chameleon" principle :)
> Indeed here I am talking as a "packager", so I guess I have different
> tradeoffs.
> 
> > The solver needs to be aware of the universe of possible versions in
> > order to be able to select (more below). It's not artificial - it just
> > depends on how big you want your package universe to be and, rather
> > more importantly, where you get the details of it from.
> 
> Both approaches add 1 package to the dependency tree, right?

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.

> > Your centralized database literally is the conf package - it already
> > exists, there's no need for a change. You are proposing replacing the
> > multiple entries in depext filtered by os-distribution with a single
> > entry called gtk3.0 and having a central repository which has the
> > os-distribution specific meanings of "gtk3.0" - it's the same thing.
> 
> I was talking under the assumption that we want to be able to express the
> desired GTK version on the opam file itself. This is where the conf-
> packages seem to not to work so well.
>
> If we don't care about including versioned dependencies on GTK, as you
> propose below, then indeed things are different.

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.

> > This confirms my original suspicion - the conf-gtk3 package should
> > absolutely not be encoding the version test of GTK3, it should simply
> > install it and just have an ultra-simple check that it works (like the
> > other conf packages).
> 
> > but the conclusion should have been to stop trying to put the version
> > test in conf-gtk3, not accuse conf- packages of being a broken
> > concept.
> 
> > In order to depend on GTK you need a notion, in opam, of what "depend
> > on GTK" means, and that notion is OS-, and even distribution-,
> > specific - so it gets wrapped in the conf-gtk3 package. We can now say
> > "in opam, to depend on GTK you depend on the conf-gtk3 package", and
> > you no longer have to worry about OSes beyond your own (knowledge).
> 
> The origin of the discussion was indeed to inform OPAM about the GTK
> version needed by lablgtk.
> 
> If we forget about versioning of system deps, then things are OK I guess,
> but that seems like not the best user experience.

Indeed, but let's not forget that the user experience if they don't have GTK3 >= 3.18 is fundamentally bad, so it's just about making opam tell the user as politely as possible that their system is too old.

It does look to me, until something neater gets added to opam, that your best way forwards is the split I propose to have conf-gtk3 holding the depext installation instructions and then having the extra package for the constraint. I wonder if a new convention for conf-at-least-gtk3-18 or something would do for now.

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

> I can see the value on the conf-package today, but for subsystems that are
> intrinsically versioned the approach doesn't seem to scale.

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?

> >> Having dependencies on depext would be a cool improvement, but that's
> >> not necessary to have today IMHO in order to have a self-contained
> >> lablgtk package.
> >
> > Again, I'm not very clear on what about the conf-gtk3 package makes
> > you feel that lablgtk3 then becomes less "self-contained".
> 
> It is not clear to me who should maintain the conf packages. If I imagine
> myself as a packager of lablgtk indeed I cannot then produce working
> packages, worse, by depending on conf-gtk3 I cannot even guarantee that my
> packages will be installable :(

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


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