Re: [Caml-list] LablGtk3 beta1

[Francois Berenger <mlists@ligand.eu>]

On 08/12/2018 03:34, Emilio Jesús Gallego Arias wrote:
> Hi Gabriel,
> 
> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
> 
>> If several OCaml package have system dependencies in common, (of
>> several versions of the same OCaml package), indicating depexts
>> per-package duplicate the information. This is what we were doing
>> before and in practice most package depexts were perpetually
>> out-of-date.
>> 
>> Some information in the conf-package is rather canonical from system
>> to system (such as: the pkg-config name, even though there is still
>> variation unfortunately), some is highly system-dependent (the package
>> name in the package manager); I think it's reasonable to also have the
>> "canonical" information in the build system.
> 
> Umm, indeed that may make sense very widely used packages, such as 
> `m4`,
> etc... I am not sure this makes sense for gtk tho; right now we have:
> 
> lablgtk2.opam
> lablgtk2-glade.opam
> lablgtk2-gnomecanvas.opam
> lablgtk2-gspell.opam
> lablgtk2-rsvg.opam
> lablgtk2-gl.opam
> lablgtk2-gnome.opam
> lablgtk2-sourceview2.opam
> 
> so adding so many conf- packages seems like a nuisance. Also it is
> harder for consumers of the library to depend on the right packages;
> this is the reason Debian uses this scheme:
> 
> liblablgtkmathview-ocaml-dev
> liblabltk-ocaml-dev
> liblablgl-ocaml-dev
> liblablgtk2-gnome-ocaml-dev
> liblablgtk-extras-ocaml-dev
> liblablgtksourceview2-ocaml-dev
> liblablgtk2-gl-ocaml-dev
> liblablgtk2-ocaml-dev
> 
> I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and
> `conf-gtksourceview`; not to say the issue with the side effects [see
> below]
> 
>> Also, conf-* packages are very early in the dependency tree, so a
>> pragmatic advantage is that they will fail early in the build,
>> typically before you have installed all the OCaml dependencies and you
>> start building the package itself.  (Also, depending on the
>> configure/build system, you may geta nice error if a dependency is
>> missing, or a crappy compilation failure that can be hard for users to
>> interpret).
> 
> In this case the error messages are the same I think. I am not sure the
> "early in the build tree" is so important tho.
> 
>> If you edit a package to update system dependencies, you have the same
>> recompilation issues.  If you have to recompile *more* in the case of
>> a conf-* package, it is because it introduced dependency sharing,
>> which is a good thing -- making the repository more maintainable.
> 
> The thing is that I am coming from a world (Debian) were package builds
> are required to be deterministic; what does editing a package to update
> system dependencies mean? How is the repository going to be more
> maintainable?
> 
> For example, in this case, installing `conf-gl` will force the
> recompilation of `lablgtk`, and `conf-gl` could be pulled by an
> unrelated package.
> 
> It seems very wrong to me that this sharing will actually force a
> side-effect on a unrelated package.
> 
> IMVHO this is very non-standard behavior that I've only seen in OPAM 
> and
> makes things less maintenable indeed, for example if you want to have
> Debian packages.
> 
>> I don't understand, the point is for lablgtk2-sourceview2 to depend
>> on conf-gtksourceview2, so you should just use the first command
>> and the conf-* package(s) will get installed as well.
> 
> I could do that, but what is the point on shipping a fake, empty 
> package
> then? `lablgtk2-sourceview2` can handle the dependencies just fine.
> 
> An even worse problem is this case: imagine package A and B both depend
> on gtksourceview, however package A requires version > 2.10 and package
> B version > 2.11.

Oh, this one is an interesting question!

You are suggesting that opam should support the installation of 
different versions of the same thing.
I think nix can do that, and that indeed looks like a current limitation 
of opam.

Regards,
F.


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