Re: [Caml-list] LablGtk3 beta1

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

Hi David,

> If I may, there seems to be a little bit of "throwing the baby out
> with the bath water" where the conf- packages are concerned.

Well, to me it means more like two solutions with different tradeoffs,
and I think the no-conf package solution seems to have a better one
IMVHO.

A kind of "warning light" for me is that none of the packaging systems I
know [admittedly little more than Debian] have this notion of
"conf-package", but rather, packages do depend on what they need.

This approach is well-tested and understood thus I feel more confident
with it, but of course I have a Debian background.

> It's also worth remembering that the layout of a package in
> opam-repository is the concern of opam-repository's maintainers (I'm
> not one, btw), not necessarily packagers.

What does this mean in practice? Is there some official policy [such as
the Debian Policy] to follow?

> At present, it is indeed not possible in opam to depend on the
> versions of system packages (with the exception of OCaml). The only
> way, without new support, is to mirror all the releases - as is done
> for the ocaml package - but that's likely to be a real PITA to
> maintain, and overkill.

I guess that the dependency on system vs opam packages seems a bit
artificial to me. If a package depends on "foo", it should not matter
much to the declarative package specification where is "foo" coming
from.

> However, the conf package remains the only place in which the depext
> information (i.e. OS-dependent packages) should be. Anything else
> involves duplication and so is fundamentally not a better solution.

I don't see where the duplication is. In one case you do:

depends: [ "conf-gtk3.0" >= ... ]

and in the other

depext: [ "gtk3.0" >= ... ]

Indeed the depext repository should contain a centralized database of
depext mappings.

> I do have one question, as I know comparatively little about
> distributions of GTK itself - if on any system I request gtk3 and I
> get, say, gtk 3.17 then on most systems, what would I need to do to
> get gtk 3.18? Is it easy? For example, if I'm on Ubuntu 16.04 and I
> want gtk3 3.20, it looks quite tricky to achieve that, I think?

In Debian-based systems getting a new release of GTK usually involves a
new major OS version; minor upgrades may be possible tho but they are
tricky.

However if the GTK version you want is ABI compatible you can indeed
backport the package without too much trouble, tho something as complex
as GTK is likely to create "suprises".

> If it's the case that the user is most likely stuck with the version
> on their system and cannot easily change it, then it looks to me as
> though this should really have been conf-gtk3.0 which simply installs
> whatever is available (no minimum version check) and then the lablgtk
> packages should check the version and fail their *build* if the
> version isn't recent enough.

The thing is then what's the point on having a conf package. It seems
like an unnecessary indirection layer. I'd rather depend on GTK itself,
as this way I get a full automated release/management workflow.

As we discussed in the other thread, conf packages seem to have a very
unpleasant property if coupled with something such as lablgtk; if they
are not 1:1 then a change in lablgtk may require a change in conf-gtk
which may in turn break an unrelated, depending package.

If they are 1:1, then the indirection seems unnecessary [at the package
level]

> The other option is still to have conf-gtk3.0 do whatever is necessary
> to install gtk3 on the system and then have an entirely separate
> conf-gtk318 package which encodes the ">= 3.18" check - that has the
> benefit of centralising OS-specific version probing. You would then
> add an entirely separate conf-gtk322 package if someone else needed
> the ">= 3.22" check. That's not terribly elegant or scalable, but
> would be a reasonable workaround for the few specific packages where
> this matters, prior to opam being able to include dependency on
> available versions of system packages.

Well that seems even worse I'd dare to say; more coupling and more
packages is going to be worse, I think.

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.

Removing duplication of dexpext mappings would indeed be an extremely
welcome thing. [I was under the impression that this was already
implemented but I am not sure anymore]

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