Re: [Caml-list] LablGtk3 beta1

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

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.

How can the sharing possibly work here?

Cheers!
E.