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 ESMTP id 8C0E35D4 for ; Wed, 19 Dec 2018 11:13:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="361042033" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Dec 2018 12:13:20 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 4C25582571; Wed, 19 Dec 2018 12:13:20 +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 A4BCD82566 for ; Wed, 19 Dec 2018 12:13:14 +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=3ABx/h7hD43XZHu9KhB/ZAUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPv+pcbcNUDSrc9gkEXOFd2Cra4c26yO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fcbglUhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRsZfWTJcDIO7?= =?us-ascii?q?YYsBAegOM+VWoIbyu1QDtge+CRW2Ce/z1jNFnH370Ksn2OohCwHG2wkgEsoBvn?= =?us-ascii?q?TRrdX1MKYSUeetw6fM0zrDdOlO2Szl54bJaB8hpfWMUqx/ccrW0UYiCxnFjlSK?= =?us-ascii?q?poz+IjiY0foCvnOU7udjSe6jkWknqxt+ojW2wMonl4rHhpoNx1zZ9ih0w5w5Kc?= =?us-ascii?q?OmREN6e9KoDZlduzyAO4drTM4uXXlktSU7x7EcpJK3YCoHxI4nyhPecfCLbomF?= =?us-ascii?q?7xDlWe2MOzl3nmhld6i6hxuq8Uiv1On8Vs6s3VdFrSdJjsPAtncX1xzc8sSHS/?= =?us-ascii?q?198Vm92TuXygze6eJJLVoqmabFKpMt2KM8m5gOvUjZAyP7llv6gLeTdko+++io?= =?us-ascii?q?7+rnYq/hpp+ZL4J7lBrzM6stl8CjG+g4NRIOX2eD9eSmyLLj5VH5QKlNjvAujq?= =?us-ascii?q?bWqpXaJcACqq69Ag9VyZoj5g2kDzam1dQYhWMIIEhEeBKBlYjpOkvBLOr2Dfel?= =?us-ascii?q?0ByQl2JHzu7HMvXIBpHWKWDb2OPtZ7847UND0yI2wMxW/I5dAbJHK/X2DBzfrt?= =?us-ascii?q?vdWzI8Mgi1xNHFBc7vzbQxUGaLD6CeB4rIsFaTrrYiC/ncPMkSojmreKtt3OLn?= =?us-ascii?q?kXJswQxVRqKux5ZCLSngRq03cXXcWmLlh5I6KUlPuwM/SOLwj1jTAy4DPzC1Ra?= =?us-ascii?q?1uv2hnWrLjNp/KQ8WWuJLExD2yT89GNjgADUqDQy+xKte0HswUYSfXGfdP1zwJ?= =?us-ascii?q?Ub/wGZ9xjVeprgCokrc=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAgCHJhpcl4Sr4rxjg3KBC4EGJ5gSg?= =?us-ascii?q?g18mFwNGBMBhEACgmgbBgEENBIBAwEBAgEBAQEBEwEBAQEBCBYGTAyCNiQBgmI?= =?us-ascii?q?BAQECAQE/AQE3AQQLCw4TJQ8BBEkTGoMIgXoMpjiCH4J2AQEFhiZSMwiMP4IWg?= =?us-ascii?q?RGCXTWKYIk5QJc9CAGIG4I5hyaBXogqh1GaAoFdY4EUMxowQ4JsgjWBCAEOh1C?= =?us-ascii?q?FQD4zgQIBASQTCwGNIAEB?= X-IPAS-Result: =?us-ascii?q?A0CRAgCHJhpcl4Sr4rxjg3KBC4EGJ5gSgg18mFwNGBMBhEA?= =?us-ascii?q?CgmgbBgEENBIBAwEBAgEBAQEBEwEBAQEBCBYGTAyCNiQBgmIBAQECAQE/AQE3A?= =?us-ascii?q?QQLCw4TJQ8BBEkTGoMIgXoMpjiCH4J2AQEFhiZSMwiMP4IWgRGCXTWKYIk5QJc?= =?us-ascii?q?9CAGIG4I5hyaBXogqh1GaAoFdY4EUMxowQ4JsgjWBCAEOh1CFQD4zgQIBASQTC?= =?us-ascii?q?wGNIAEB?= X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="289578931" Received: from x80.org ([188.226.171.132]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 19 Dec 2018 12:13:13 +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=YYt8uDzd5QHNro1IZ6RsYHDXtWORxg963shxhkSYrWU=; b=bjpCNovC/53LJC1z/Un4a53PCU 9DW5Fj/2rYe16vqyRFbPCClYKbA/eSO3zs5oDEZByk/oY70iKf8oqMRisB7/iLIhTW/f67w/eWaVt x3+2Us1545gILQuvKUgX5P7nnD2s7VIITfFrTWL4SfxBXJZNYmZJJgwER9o4CaoyoAL8=; 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 1gZZmp-0006Qk-1E; Wed, 19 Dec 2018 11:13: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> <877eg6jos4.fsf@x80.org> X-Url: https://x80.org/emilio/ Mail-Followup-To: David Allsopp , Jacques Garrigue , Mailing List OCaml Date: Wed, 19 Dec 2018 12:13:10 +0100 In-Reply-To: (David Allsopp's message of "Wed, 19 Dec 2018 10:15:00 +0000") Message-ID: <8736qtepmh.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: 17249 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, David Allsopp writes: > 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! > :) Sorry David I don't follow, but I don't see where the "n" copies gets introduced in the approach I propose, could you provide an example? > 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...) I am not sure I can declare myself a fan of the "chameleon" principle :) Indeed here I am talking as a "packager", so I guess I have different tradeoffs. > 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. Both approaches add 1 package to the dependency tree, right? > 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. I was talking under the assumption that we want to be able to express the desired GTK version on the opam file itself. This is where the conf- packages seem to not to work so well. If we don't care about including versioned dependencies on GTK, as you propose below, then indeed things are different. > 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). > 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. > 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). The origin of the discussion was indeed to inform OPAM about the GTK version needed by lablgtk. If we forget about versioning of system deps, then things are OK I guess, but that seems like not the best user experience. 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? I can see the value on the conf-package today, but for subsystems that are intrinsically versioned the approach doesn't seem to scale. >> 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". It is not clear to me who should maintain the conf packages. If I imagine myself as a packager of lablgtk indeed I cannot then produce working packages, worse, by depending on conf-gtk3 I cannot even guarantee that my packages will be installable :( 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