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 c5ff346549e7 (Postfix) with ESMTPS id 301705D4 for ; Wed, 19 Dec 2018 01:20:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,370,1539640800"; d="scan'208";a="360964108" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Dec 2018 02:20:19 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id E6F1E82566; Wed, 19 Dec 2018 02:20:19 +0100 (CET) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 8B281824CF for ; Wed, 19 Dec 2018 02:20:15 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=e@x80.org; spf=Pass smtp.mailfrom=e@x80.org; spf=Pass smtp.helo=postmaster@x80.org IronPort-PHdr: =?us-ascii?q?9a23=3A8h6AER/wIK/CAP9uRHKM819IXTAuvvDOBiVQ1KB4?= =?us-ascii?q?1ugcTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+557ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsaS2RfQ8hRUCJBDI2+?= =?us-ascii?q?YIUMAeUOMvpXopLhp1cStxayGRWgCfntxzJOm3T43bc60+MkEQze0wIgGtMOsH?= =?us-ascii?q?DVrNXyLKgcVf66zLLS1TXYd/xY2C3y6IzMch8/rvGMWqp/fNbLyUkuDQzFlUib?= =?us-ascii?q?pIv7MD6O2eUAsHSX4/BnVeK1hG4qsgd8qSWsyMc0koTFm4EYx1Pe+Sln3oo4JM?= =?us-ascii?q?e0RFN5bNK5Cpdcqi+XO5VuTs4hQmxkojs2xqEEtJKhfCUHyY4rywPeZvGFdYWD?= =?us-ascii?q?/wjtW/yLIThigXJoYLK/iAi28Uin0uD9Wcq53EpQoipCiNnMuWgB1x3V6seZVv?= =?us-ascii?q?tw5lqt1DWM2gzJ9O1IP0E5mbDGJ5Mj37I8jIcfvErdEiPunUX5lq6WdkEq+uiy?= =?us-ascii?q?7OTnZ63rqYGHOo57iQzyLr4imsulAeQ3KgQORXSU+fyg1L3/+k30WKlFgeczkq?= =?us-ascii?q?ndqZzaIcUbprWlAwJOyYYi6xO/Dy+839gCnHkHKkhFeBOdgITzNVHOOqOwMfDq?= =?us-ascii?q?r12ykTsj7vTCJbr5Gt2ZImLK1bHsYq1V7kNAwREvxNtcoZlTD+dSDuj0Xxrcsd?= =?us-ascii?q?3cDxgOEQGvUf3QJ9x50o4RXlWmGK6QK+uGvHeYtrppJPODMtxG8A3hIuQosqa9?= =?us-ascii?q?xUQynkUQKOzwhcNOOSKIW89+KkDcWkLCx9IIEGMEpA07Hb762AXEViRcNS/rA/?= =?us-ascii?q?AMowojAYfjNr/tA5i3ie3TzHfjWJpMaTIeUw3eITLTb4yBHsw0RmeSL8tmw24U?= =?us-ascii?q?BeDnTJUuh0ij?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCcmxlcl4Sr4rxkHgEGBwaBZYJmg?= =?us-ascii?q?QYnmh+ZVw0rAYRAAoJbGwYBBDQSAQMBAQIBAQEBARMBAQEBAQgWBkwMgjYkAYJ?= =?us-ascii?q?iAQEBAgEBPwEBNwEECwsOExQRDwEESS6DB4F6DKYBgh+CdgEBBYYmUjMIjD+CF?= =?us-ascii?q?oERgxKEdIVsiXaWW1cIAYpShyaKB4dPmXaBXWOBFDMaMEOCbIIbGohnhUA+M4E?= =?us-ascii?q?CAQEkEwsBilWCSwEB?= X-IPAS-Result: =?us-ascii?q?A0BrAQCcmxlcl4Sr4rxkHgEGBwaBZYJmgQYnmh+ZVw0rAYR?= =?us-ascii?q?AAoJbGwYBBDQSAQMBAQIBAQEBARMBAQEBAQgWBkwMgjYkAYJiAQEBAgEBPwEBN?= =?us-ascii?q?wEECwsOExQRDwEESS6DB4F6DKYBgh+CdgEBBYYmUjMIjD+CFoERgxKEdIVsiXa?= =?us-ascii?q?WW1cIAYpShyaKB4dPmXaBXWOBFDMaMEOCbIIbGohnhUA+M4ECAQEkEwsBilWCS?= =?us-ascii?q?wEB?= X-IronPort-AV: E=Sophos;i="5.56,370,1539640800"; d="scan'208";a="289515010" Received: from x80.org ([188.226.171.132]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 19 Dec 2018 02:20:14 +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=+mqBE1j2+F68jP3iwy0GgZJWyGzx6DmoQ7PGf21E5do=; b=tMZB7e2d1d4ovGZTze8blOgsTf PYcqMBVarHwlZ20m0orKSMClhEpfyPdFcuabWQLn1XdL1GY0GXstC8sHJ7OvbI6e6ssBcS51PNz/e kJGcaNovmsStQGXMeMVPSRjMDDtfR2Hr5TGnUkZB0rScxmgsuqHUVelK2LaPyG3zsOZs=; 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 1gZQWx-0000uD-PR; Wed, 19 Dec 2018 01:20:11 +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> X-Url: https://x80.org/emilio/ Mail-Followup-To: David Allsopp , "Jacques Garrigue" , Mailing List OCaml Date: Wed, 19 Dec 2018 02:20:11 +0100 In-Reply-To: (David Allsopp's message of "Tue, 18 Dec 2018 14:33:51 +0000") Message-ID: <877eg6jos4.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 Reply-To: =?utf-8?Q?Emilio_Jes=C3=BAs_Gallego_Arias?= X-Loop: caml-list@inria.fr X-Sequence: 17247 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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