caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Allsopp <dra-news@metastack.com>
To: "Emilio Jesús Gallego Arias" <e@x80.org>
Cc: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>,
	Mailing List OCaml <caml-list@inria.fr>
Subject: RE: [Caml-list] LablGtk3 beta1
Date: Wed, 19 Dec 2018 10:15:00 +0000	[thread overview]
Message-ID: <E51C5B015DBD1348A1D85763337FB6D901AE527798@Remus.metastack.local> (raw)
In-Reply-To: <877eg6jos4.fsf@x80.org>

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

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! :)

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

This is an apples vs oranges comparison - Debian (i.e. apt) only has to worry about what apt can install. Imagine instead an apt package which has to depend on being able to install a dependency from either yum, nix, brew, chocolatey, ... oh, and they put your dependency in different combinations of packages *and* use different version systems... oh, and on Windows, opam may choose to download the C sources for GTK3 and build them (in opam)...

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

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

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

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.

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

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.

The mistake in what you're describing is *how* it is possible to map a version constraint.

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

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

In terms of the versioning problem, opam has two notions for selecting between different packages - dependency and availability. Availability is things about your environment (e.g. os, architecture and, prior to opam 2, OCaml version). Availability is a static check, used to eliminate packages from consideration by the solver. Dependency is dealt with by the solver, and results in a choice between multiple *buildable/installable* packages. It makes no sense for conf-gtk3 to have multiple versions of the package (i.e. for dependency) if you cannot actually install them - this is the problem described in the thread, 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.

What is really needed is a hybrid kind of availability test which could indeed be encoded as a version on the depext specification (that version check would still need to be os-dependent). This I know is being considered already, but it is quite a large change in the solver architecture, since as far I can see it either requires multi-stage solving (which is something we've really tried to avoid in opam) or much deeper querying of the OS package manager to get what is available and what could be available. Essentially, this would generalise even further the configuration which exists to detect your system OCaml compiler's version. 

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

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

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

As far as I can see, this is based on an incorrect notion of where lablgtk should be detecting the version of GTK which is installed - it should not be encoded in the conf-gtk3 package, as I elaborated below...

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

Again, I'm not very clear on what about the conf-gtk3 package makes you feel that lablgtk3 then becomes less "self-contained".

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

Again, duplication of depext mappings is already removed - that's what we use conf packages for...


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

  reply	other threads:[~2018-12-19 10:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  6:33 Jacques Garrigue
2018-12-06 10:05 ` Louis Gesbert
2018-12-06 10:35 ` Gabriel Scherer
2018-12-07 10:04 ` Emilio Jesús Gallego Arias
2018-12-07 10:25   ` Gabriel Scherer
2018-12-07 18:34     ` Emilio Jesús Gallego Arias
2018-12-11  3:09       ` Francois Berenger
2018-12-11 11:34         ` Louis Gesbert
2018-12-14 11:41           ` Emilio Jesús Gallego Arias
2018-12-14 11:38         ` Emilio Jesús Gallego Arias
2018-12-16  8:12           ` Jacques Garrigue
2018-12-17 12:11             ` Emilio Jesús Gallego Arias
2018-12-18 14:33               ` David Allsopp
2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
2018-12-19 10:15                   ` David Allsopp [this message]
2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
2018-12-19 11:50                       ` David Allsopp
2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
2018-12-20 11:33                           ` David Allsopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E51C5B015DBD1348A1D85763337FB6D901AE527798@Remus.metastack.local \
    --to=dra-news@metastack.com \
    --cc=caml-list@inria.fr \
    --cc=e@x80.org \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).