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 551625D4 for ; Thu, 20 Dec 2018 11:33:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,376,1539640800"; d="scan'208";a="361217875" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 20 Dec 2018 12:33:23 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 22DA382566; Thu, 20 Dec 2018 12:33:23 +0100 (CET) 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 6F5BB824CF for ; Thu, 20 Dec 2018 12:33:16 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail149081.authsmtp.net IronPort-PHdr: =?us-ascii?q?9a23=3AhwlzuB8GOn2U8/9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1egcTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?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?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsaS2RfQ8hRSyJPDICy?= =?us-ascii?q?b4QNDuoOIelWoIb6p1YVsRu+HBWgCP/zxjNUm3P727Ax3eQ7EQHB2QwtB9wAv2?= =?us-ascii?q?7KrNX0KagZTPy4zK3MzTXYaPNWwS/945XPfx88u/GDR6t8cczPxkghDAPIlVCQ?= =?us-ascii?q?ppL5PzyPzeQNr3KU4PZjVe61l2EnrARxryGpy8wxiYfJnpoYx1Ha+Slj3Yo4K8?= =?us-ascii?q?e0RFN0bNOgCpddtDyWO5NrTs4iR2xkojs2xqEatZKheCUHyI4rywPeZvGJa4SI?= =?us-ascii?q?7AzsWeWNLTp9gX9oeL2yihSu/kWlxODzSsa53EhPoyVbj9XDq2oC2hnN5ceaUP?= =?us-ascii?q?Rx4EGs0iuV2Q/J8OFLO0U0mLLbK5E/xr4wkYIesUPeHi/qnUX5lq6WdkE59uWn?= =?us-ascii?q?7+nrfrbrqoKGO4BulwH+LqQumte6AeQkKggCRW6b9vqg1LH7/E35RqtFjuEun6?= =?us-ascii?q?TYrpzWP9kXq6CjDwNI3Ysu7wyzAjS73NgAmHkINlNFeBaJj4jzPFHOJej1Auql?= =?us-ascii?q?g1u2iTtrwe7JP7P6ApjWK3jMjqvhcqxm605A0gU80dNf64hIBbEGJfL/QlXxu8?= =?us-ascii?q?DADh8lLwy0xP7qB8ln2YMbXWKDG6uZMKLJsV+U/e8vOOmNZIoNuDnnMfQl5vju?= =?us-ascii?q?jWU4mVAHZ6Wp04EXOziEGaFLJkSdYH3boNoag3w9kQM6SOHlj2qrSz9afD7mUo?= =?us-ascii?q?ostml9D5ipW9TtXIeo1ZCIwia3VrRSYntBEkjERXvyfsCCVugXQCefPsZ6jjUP?= =?us-ascii?q?Vv6qTIp3hkLmjxPz17cydrmcwSYfr5+2kYEtv7SCxyF3ziR9CoGm60/ISmh1mm?= =?us-ascii?q?0SQDpvgfJ6rFB00UuK2qs+iPtdR4UKu6F5FzwiPJuZ9NRUTsjoU1ucLNKEVF+9?= =?us-ascii?q?XtytAnc6Sddjm4ZTMXY4IM2ri1X45wTvA7IRkObbVpsp7qfV3nyoe5clmy+A3b?= =?us-ascii?q?Q9j0IjXtMJM2C61PZy?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AABFfRtch1GVDT5kHgEGBwaBUwcLA?= =?us-ascii?q?YEwJYIWJwqMa4sdUAEBBoE1E2mIJ446gXsLAQEsgUuCdQKCaxoHAQQyBw0BAwE?= =?us-ascii?q?BAgEBAQEBEwEBAQoLCQgpL4I2JAGCYQEBAQMBeRACAQgYLjIlAgQOBQgSAYMHg?= =?us-ascii?q?XUFCAEDAakaiiyMP4EPgQeBEUaBKiRJNYUDgzeCJgKJeYYqkEBaCZFlEgaBX4U?= =?us-ascii?q?fgzGHLpZQgxYCBAsCFIFNB2yBFDMaI1CCbII1jiZygQchjCABgR4BAQ?= X-IPAS-Result: =?us-ascii?q?A0A6AABFfRtch1GVDT5kHgEGBwaBUwcLAYEwJYIWJwqMa4s?= =?us-ascii?q?dUAEBBoE1E2mIJ446gXsLAQEsgUuCdQKCaxoHAQQyBw0BAwEBAgEBAQEBEwEBA?= =?us-ascii?q?QoLCQgpL4I2JAGCYQEBAQMBeRACAQgYLjIlAgQOBQgSAYMHgXUFCAEDAakaiiy?= =?us-ascii?q?MP4EPgQeBEUaBKiRJNYUDgzeCJgKJeYYqkEBaCZFlEgaBX4UfgzGHLpZQgxYCB?= =?us-ascii?q?AsCFIFNB2yBFDMaI1CCbII1jiZygQchjCABgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.56,376,1539640800"; d="scan'208";a="361217819" Received: from outmail149081.authsmtp.net ([62.13.149.81]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 12:33:08 +0100 Received: from punt18.authsmtp.com (punt18.authsmtp.com [62.13.128.225]) by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id wBKBX7PX056785 for ; Thu, 20 Dec 2018 11:33:07 GMT (envelope-from dra-news@metastack.com) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt18.authsmtp.com. (8.15.2/8.15.2) with ESMTP id wBKBX7qg072142; Thu, 20 Dec 2018 11:33:07 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 wBKBX5e5050150 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2018 11:33:06 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 wBKBX4oh003736; Thu, 20 Dec 2018 11:33:04 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; Thu, 20 Dec 2018 11:33:04 +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: AQHUl7mqcvOZnBA/G06CdkvKExYwhqWHeVKg Date: Thu, 20 Dec 2018 11:33:04 +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> <87d0px4ggh.fsf@x80.org> In-Reply-To: <87d0px4ggh.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: 051fb4fd-044b-11e9-8e31-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgESJgdEAn1U UHkJW1VcQFxwU2B2 YQpXIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFlsKWsaclBDeHtw ZENiEHJSXEB8O0Z4 QxgGETtSeGdkbDIC UUENfh5cJQBLYx9F a1V+U3VeMGQObjQC Ml17DBs4ODEaLCVO XjRFCVsYRWkXHWV0 TR0eFGxH X-Authentic-SMTP: 61633634383431.1038: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: 17255 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 > > 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 =3D 1, but that's not really the > > point. >=20 > 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. >=20 > So indeed maybe the core question is whether using "dummy" package for > capturing this is the best abstraction. Please let's not have another file format in opam :-/ > > 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: backports). >=20 > 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 >= =3D > 3.18-4 and B needs 3.20-2 where -x is the Debian version] The current model can, inasmuch as you can create a dummy package whose pur= pose is to express what ">=3D 3.18" actually means for each individual pack= ager. You can imagine that if you were talking about the Linux kernel, you = may well have > 4.xx.yy for a stock kernel but a special case of > 3.10.x f= or RHEL, because the thing you want is backported (obviously a slightly ban= al example, because you'd never determine a kernel feature by version numbe= r, but hopefully it serves the point - there are other libraries where you = might). The current model can deal with packages A and B neatly, yes - what's not n= eat is that two separate packages get installed (conf-at-least-gtk-3-18 and= conf-at-least-3-20). The build instructions for those two conf packages wo= uld include Debian-specific strings to test for the -x part. It's definitel= y not a perfect solution, but your proposal of versioned depexts I think si= mply moves the trade-off to be considerable complexity in the depext code f= rom having a relatively small number of these dummy packages. > > 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. >=20 > 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? I'm sorry, I'm still not following the comparison here. Having 1 conf- pack= age for each depext sounds entirely correct, in terms of the "database" of = OS-specific package names for that depext. > > 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. >=20 > 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. Indeed - but the user experience is entirely correct to say "we can't insta= ll conf-gtk3 because you don't have the system libraries for it". It would = then be correct to say "we can't install conf-at-least-gtk-3-18 because you= have GTK3 < 3.18". Not likely for gtk3, but imagine you were installing lablgtk3, marialablgtk= 3, librelablgtk3 and lablgtk3Org all of which, despite disagreeing with Jac= ques on how lablgtk3 should run as a project, all definitely agree that the= y depend on the underlying GTK3 binaries - the conf-gtk3 package gives a mu= ch better user experience if the GTK3 package is < 3.18 because it's the si= ngle failure, as opposed to all of them failing individually. The conf-at-least-gtk-3-18 package would be able to display a very clear op= am error message explaining the problem as the only error which can occur i= s that.=20 > >> 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. >=20 > 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. So provide the two packages in separate opam repositories? Yeouch. The user= experience for the -conf version is capable of being slightly clearer, ina= smuch as on a build error you can be reasonably sure that the error is the = lack of GTK3, whereas a build error in lablgtk3 could be other things - opa= m's own error messages (in post-messages) are much clearer to consume than = trying to read the build output, which is all you'd have in the other case. > > 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? >=20 > 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. If there are 8 distinct depexts, then there should be 8 distinct conf- pack= ages - I'm sorry if your library is complicated :o) But look on the other side - these conf packages are only normally updated = to include package names missing for other distributions - in other words, = other contributors quietly improving them. It seems to be me that you're an= ticipating a maintenance burden which won't exist here, and doesn't exist f= or the conf- packages already in opam-repository. > > 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... >=20 > 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] This is almost entirely separate - at present, Dune doesn't care about conf= - packages, and you don't need to specify them. Dune also has no knowledge = of depext, so even in a multi-project tree you're still responsible for ens= uring that your system libraries are present, not Dune. The work going on i= n Dune to be able to generate opam files automatically is already aware of = the need to support them. 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=