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 4D9A45D4 for ; Wed, 19 Dec 2018 11:51:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="361048007" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Dec 2018 12:51:08 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 2ED9782567; Wed, 19 Dec 2018 12:51:08 +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 31F7C824CF for ; Wed, 19 Dec 2018 12:51:04 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail148102.authsmtp.net IronPort-PHdr: =?us-ascii?q?9a23=3AiqaNOxTkokKAbv6tCOMfiNR5ftpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6yYhKN2/xhgRfzUJnB7Loc0qyK6/CmATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSizexfbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRBDI2i?= =?us-ascii?q?coUPE+QPM+VWr4b/plsBsRSwCgarBO701j9In2P60bEm3+g9DA3L2hErEdIUsH?= =?us-ascii?q?TTqdX4LKkcXvqrzKnJ0DrIcu9b2TP56IjTdRAhuemMVq93fMXM00kgDRrJjlOO?= =?us-ascii?q?po3rJDOYzeENvHaH7+V6TuKvl3QopB1yojS12sgsjYzJi5sTx1vZ9it52J44KN?= =?us-ascii?q?ymREJhfNKpHoFcuzyVOoZ1WM8uXn1ktDgixrEbuZO2eDIGxIk7yxLDcfCKd4iF?= =?us-ascii?q?7gj+WOuQLzp0nHxld6y8ihqu9EWtz+3xW8a23VlWqydInMXDu38T2xHW9MeLV+?= =?us-ascii?q?Zy8V2k1DmRyg/c8P9ILEYpnqTBMZEh2KQ/lp8LvETDACD2nEL2gbeRdkU55uio?= =?us-ascii?q?7v7oYrTippOBOIJ5iRzyPrgwlsClG+s4LxQOX2iA+eS5yL3j5Vf1QLNUgf0qiq?= =?us-ascii?q?XZsZbaKtoHpqOhAgJZzJwv5wuxAju8zdgVknoKIEhYdB6bkYTlI1TOL+r5Dfe7?= =?us-ascii?q?jVSsijBrx/XeM7L8GJXCNGHPkLH/crdz8E5R0w8zws5D551OEbEBPOj8VVPytN?= =?us-ascii?q?DCEhA5NAm0z/79CNphzoMeRX6PAqiBPazOq1CI4+YvL/CIZI8Uozb9N+Mo5+Xu?= =?us-ascii?q?jH88gV8SZ7Ol3ZoRaHCiH/RpOV+VYXT2goRJLWBfkw8/SO3tv3+PSqxIUFm7W6?= =?us-ascii?q?Yx6TYMIZinBJyLEo2FkOzZmiChEcsFSHpBDwWgGGnpe82tX/MXbzqKapttiDVB?= =?us-ascii?q?U7W+UKck2A2nrxPzwLkhJe3RrH5L/an/3cR4srWA3So58iZ5WoHEiznUHjNE21?= =?us-ascii?q?gQTjpz55hR5El0y1ONy6992qEKENFP7uhVWww5c5Xbyr4jUoygakf6Zt6MDW2e?= =?us-ascii?q?bJC+GzhoE4A0zsMHeFp0ENbkhRfGjXLzXu0l0oeTDZlxyZrymnj8I8EnmyTByb?= =?us-ascii?q?UkhlgiG5cfbDX8wKdi6wjIApLR1UOUi/TyeA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAACpLxpcmGaUDT5kHAEBAQQBAQcEA?= =?us-ascii?q?QGBUQcBAQsBgTAqghEnCowMX4sdUgaBNRNpiCeOOoF7CwEBLIRAAoJoGgcBBDA?= =?us-ascii?q?JDQEDAQECAQEBAQETAQEBAQEICwsGKS+CNiQBgmEBAQEBAgF5BQsCAQgYLjIlA?= =?us-ascii?q?gQOBQgSgwiBdQUIAQMBqHiKMIw/gQ+BB4ERRoEqbTWFA4M3giYCiTdAhieRFgm?= =?us-ascii?q?IG4I5hw4SBoFej3uZWwIECwIUgUZ6gRQzGiNQgmyCNYEIAQ6ND3KBByGMIAGBH?= =?us-ascii?q?gEB?= X-IPAS-Result: =?us-ascii?q?A0ASAACpLxpcmGaUDT5kHAEBAQQBAQcEAQGBUQcBAQsBgTA?= =?us-ascii?q?qghEnCowMX4sdUgaBNRNpiCeOOoF7CwEBLIRAAoJoGgcBBDAJDQEDAQECAQEBA?= =?us-ascii?q?QETAQEBAQEICwsGKS+CNiQBgmEBAQEBAgF5BQsCAQgYLjIlAgQOBQgSgwiBdQU?= =?us-ascii?q?IAQMBqHiKMIw/gQ+BB4ERRoEqbTWFA4M3giYCiTdAhieRFgmIG4I5hw4SBoFej?= =?us-ascii?q?3uZWwIECwIUgUZ6gRQzGiNQgmyCNYEIAQ6ND3KBByGMIAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="289583902" Received: from outmail148102.authsmtp.net ([62.13.148.102]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 12:51:02 +0100 Received: from punt17.authsmtp.com (punt17.authsmtp.com [62.13.128.224]) by punt22.authsmtp.com. (8.15.2/8.15.2) with ESMTP id wBJBp1i5057064 for ; Wed, 19 Dec 2018 11:51:01 GMT (envelope-from dra-news@metastack.com) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt17.authsmtp.com. (8.15.2/8.15.2) with ESMTP id wBJBp1uX078901; Wed, 19 Dec 2018 11:51:01 GMT (envelope-from dra-news@metastack.com) Received: from romulus.metastack.com (114.212-105-213.static.virginmediabusiness.co.uk [213.105.212.114]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id wBJBowfF067832 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2018 11:50:59 GMT (envelope-from dra-news@metastack.com) Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id wBJBovxu009150; Wed, 19 Dec 2018 11:50:57 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 11:50:57 +0000 From: David Allsopp To: =?iso-8859-1?Q?Emilio_Jes=FAs_Gallego_Arias?= CC: Jacques Garrigue , Mailing List OCaml Thread-Topic: [Caml-list] LablGtk3 beta1 Thread-Index: AQHUl4vTcvOZnBA/G06CdkvKExYwhqWF66Eg Date: Wed, 19 Dec 2018 11:50:56 +0000 Message-ID: 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> In-Reply-To: <8736qtepmh.fsf@x80.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [159.100.95.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 5a35101a-0384-11e9-903a-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgESJgRNAn1U UHkJW1VcQFxwU2Z1 YQ9YIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFlsKGstMFMweHh3 bUVgEHJeX0F6O0Ms QUtVFWxXeGdjYGQC UUENfh5dcAAbYxYW OFZ6UCFfY2AHYjQC Ml17DBs4ODEaLCVO XjRFCVsYRWkXHWV0 TR0eFGxH X-Authentic-SMTP: 61633634383431.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] LablGtk3 beta1 Reply-To: David Allsopp X-Loop: caml-list@inria.fr X-Sequence: 17250 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: Emilio Jes=FAs Gallego Arias wrote: > David Allsopp writes: >=20 > > 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! > > :) >=20 > 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? You were advocating putting the depext information (as required at the mome= nt - 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, wh= ich would have to duplicate that same depext information. Granted, at the m= oment n =3D 1, but that's not really the point. Even if you carve the OS-specific package names off somewhere else, "gtk3 >= =3D 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: backpor= ts).=20 > > 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...) >=20 > 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. >=20 > > 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. >=20 > Both approaches add 1 package to the dependency tree, right? No - depexts are not part of the dependency tree for the solver, they're me= tadata for a package which has already been selected by the solver - that's= why version constraints on them are harder to achieve, because the package= s have already been selected. > > 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. >=20 > 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. Well, it's so much caring, as being able to! It's just not that the conf- p= ackages 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. > > 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). >=20 > > 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. >=20 > > 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). >=20 > The origin of the discussion was indeed to inform OPAM about the GTK > version needed by lablgtk. >=20 > If we forget about versioning of system deps, then things are OK I guess, > but that seems like not the best user experience. Indeed, but let's not forget that the user experience if they don't have GT= K3 >=3D 3.18 is fundamentally bad, so it's just about making opam tell the = user as politely as possible that their system is too old. It does look to me, until something neater gets added to opam, that your be= st way forwards is the split I propose to have conf-gtk3 holding the depext= installation instructions and then having the extra package for the constr= aint. I wonder if a new convention for conf-at-least-gtk3-18 or something w= ould do for now. > 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 nam= es? One of them must fundamentally have a higher version number than the ot= her, and the one which depends on conf-gtk3 is always going to attempt to i= nstall it - opam won't magically fall back to the other one. > I can see the value on the conf-package today, but for subsystems that are > intrinsically versioned the approach doesn't seem to scale. 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? > >> 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". >=20 > 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 :( Nothing prevents the maintainer of lablgtk3 also being the maintainer of co= nf-gtk3 and conf-at-least-gtk3-18 (or whatever). If one chooses just to mai= ntain lablgtk3 and depend on conf-gtk3 then the installability of that is t= he concern of opam-repository maintainers - that's what we have CI for. Som= eone 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 see= m 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 h= as) been maintained by ocamlfind's author... David --=20 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=