From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id EC064824CF for ; Wed, 19 Dec 2018 17:41:21 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=e@x80.org; spf=Pass smtp.mailfrom=e@x80.org; spf=Pass smtp.helo=postmaster@x80.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of e@x80.org) identity=pra; client-ip=188.226.171.132; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="e@x80.org"; x-sender="e@x80.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of e@x80.org designates 188.226.171.132 as permitted sender) identity=mailfrom; client-ip=188.226.171.132; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="e@x80.org"; x-sender="e@x80.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@x80.org designates 188.226.171.132 as permitted sender) identity=helo; client-ip=188.226.171.132; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="e@x80.org"; x-sender="postmaster@x80.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" IronPort-PHdr: =?us-ascii?q?9a23=3A0+PPeB2jqkwegtpAsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?se0TKPad9pjvdHbS+e9qxAeQG9mDu7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxGDIOy?= =?us-ascii?q?YYkAAekPMulXs4bwvEcOoQekCAWwGO/i0D1Fi3nr1qM6yeQhFgTG0RQvEdILsX?= =?us-ascii?q?TUqNT1NKAKXu6x0qbI1i/bb+hO1jn88ofIdhQhru+DXbJ3acXc1VMvFwLfgVWL?= =?us-ascii?q?tIfoOC2a2/8CsmWY8+ZsT+Wvi3QoqwxopDWk28QiipHRi44IyV3J9j91zJgrKd?= =?us-ascii?q?C5UkJ3fNypHIZKuy2HOYZ6XNsuTmJptSog17EKpZy2cDIKxZkm3RLTdv2KfoqO?= =?us-ascii?q?7xn+TuieOy14i2hgeL+nhxa970ygyurkW8i701tGsjBJkt7WtnACzxDT686HRe?= =?us-ascii?q?Vh/kq5xDqC1APe5vtaLUwqlKfXMYMtz7wtmpYJrEjOEDH6lF3zjKCMd0Uk/uao?= =?us-ascii?q?6/7gYrXjvpKTKZR5iw79P6gygMC/Bv44MgcWU2iB5eu8zKHj/VH+QLhSkvI5iK?= =?us-ascii?q?zZsJTDKcQfp665GBNV35046xe/CjemyM4XkWMGLFJDYhKHjpLmN0vAIPDiXr+D?= =?us-ascii?q?hAGAmSlqy7jvOrn6BY3VZizPir6ke7ti8GZZxRY61sxW7JESAbYEdqHdQEj04f?= =?us-ascii?q?HdDxs4NDuWzv11E+JS34caVG2INYaDMarJ+QuFzvJ/e6+LfoBD62W1EOQs+/O7?= =?us-ascii?q?1SxxolQaZ6T8mMJPMCnpTMQjGF2QZD/XuvlEFG4LugQkS+m72k3SCXhUfXngBv?= =?us-ascii?q?tgtAF+M5qvCML4fq7omKaIjXWrTsUQYXpJWAjVTCXYMr6cUvJJUxq8Z89sljtV?= =?us-ascii?q?B6jxE8kmzx787QI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBQcxpcl4Sr4rxkhH2BBieYEoINm?= =?us-ascii?q?VgNGBMBgUuCdQKCaxsGAQQ0EgEDAQECAQEBAQETAQEBAQEIFgZMDII2JAGCYgE?= =?us-ascii?q?BAQIBAT8BATcBBAsLDhMlDwEESRMagwiBegynT4IfgnYBAQWGJlIzCIw/ghaBE?= =?us-ascii?q?YMSimCJeZZjWggBkXqKCIdRlkaDPIFdY4EUMxowQ4JsgjWIZ4VAPjOBAgEBJBM?= =?us-ascii?q?LAY0gAQE?= X-IPAS-Result: =?us-ascii?q?A0D/AQBQcxpcl4Sr4rxkhH2BBieYEoINmVgNGBMBgUuCdQK?= =?us-ascii?q?CaxsGAQQ0EgEDAQECAQEBAQETAQEBAQEIFgZMDII2JAGCYgEBAQIBAT8BATcBB?= =?us-ascii?q?AsLDhMlDwEESRMagwiBegynT4IfgnYBAQWGJlIzCIw/ghaBEYMSimCJeZZjWgg?= =?us-ascii?q?BkXqKCIdRlkaDPIFdY4EUMxowQ4JsgjWIZ4VAPjOBAgEBJBMLAY0gAQE?= X-IronPort-AV: E=Sophos;i="5.56,373,1539640800"; d="scan'208";a="361102395" Received: from x80.org ([188.226.171.132]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 19 Dec 2018 17:41:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=x80.org; s=chaosisorder; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=F8WU82pOS+sM/Pai/QJD6dO00DkInZd4knf0zlw7tt0=; b=sSlV4DZlrs+0ot2XDhSRl2oXaK bJFKwskyc6zdPVX0pYKNltfwjCspoD9Y4hNB8W+djetSWhLFOcJicPEmMRYHkmvXTdXvmMp5mJR7q K4wcN8RXohwzp6Y0EMAaQdpq1U67DfUY7MrHqTowAmDhmz0bvnAlFQwt+gjJtbwI0i8M=; Received: from [86.107.56.167] (helo=lasserre) by x80.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gZeuN-000198-Ea; Wed, 19 Dec 2018 16:41:19 +0000 From: =?utf-8?Q?Emilio_Jes=C3=BAs_Gallego_Arias?= To: David Allsopp Cc: Jacques Garrigue , Mailing List OCaml Organization: X80 Heavy Industries References: <966B3CBE-29BB-4336-BDBF-0012723E7099@math.nagoya-u.ac.jp> <87va45odpo.fsf@x80.org> <8736r9mbho.fsf@x80.org> <87d0q4tk2v.fsf@x80.org> <87o99kmjyo.fsf@x80.org> <877eg6jos4.fsf@x80.org> <8736qtepmh.fsf@x80.org> X-Url: https://x80.org/emilio/ Mail-Followup-To: David Allsopp , Jacques Garrigue , Mailing List OCaml Date: Wed, 19 Dec 2018 17:41:18 +0100 In-Reply-To: (David Allsopp's message of "Wed, 19 Dec 2018 11:50:56 +0000") Message-ID: <87d0px4ggh.fsf@x80.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] LablGtk3 beta1 David Allsopp writes: > 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. Ah, indeed sorry I was not clear; indeed what I was thinking is about a model where the os-dependent information is centralized, but not by using a package, but a proper database of mappings / recipes. So indeed maybe the core question is whether using "dummy" package for capturing this is the best abstraction. > 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). Indeed that's a problem; I would say that OPAM could talk about upstream version, but in some cases that may not be enough. But this is something the current model cannot do very accurately either, right? [Like if for example two packages A, B depend on gtk where A needs GTK >= 3.18-4 and B needs 3.20-2 where -x is the Debian version] > 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. I meant that depexts are not, however the `conf- package is. So if we need 1 conf- package for each depext that doesn't seem to be a huge improvement right? > 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. Sure, I was being concerned for user experience with `conf-gtk` where the package can be installed but the bounds are not the right ones. >> 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. Sorry for the bad explanation. I meant to provide them "in parallel", like I could package lablgtk in this way or in that other way. Both of them would fail in the same way. > 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? I am still not sure the release workflow is superior: we'd have to introduce 8 additional conf- packages, and we'd have to maintain the OS-dependent info in the repos anyways. > 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... I am trying to move all the OCaml software I work on to Dune + dune-release, thus in the future indeed packages will be maintained in-tree [by however takes care of the build system] Best, E.