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 F36A15D4 for ; Wed, 19 Dec 2018 10:15:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="361026824" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Dec 2018 11:15:39 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 334E282568; Wed, 19 Dec 2018 11:15:39 +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 7359B82548 for ; Wed, 19 Dec 2018 11:15:32 +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@outmail148106.authsmtp.co.uk IronPort-PHdr: =?us-ascii?q?9a23=3Am05HjxfQ9HUEesHKdzU0nKdOlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcS9ZB7h7PlgxGXEQZ/co6odzbaO4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTahYr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2h?= =?us-ascii?q?YYsTAeQPPuhYoIv8p1QSohWxCg6sCfjzyj9RmnP6wbE23/g8HQzAwQcuH8gOsH?= =?us-ascii?q?PRrNjtOqkdS/61zKjVwj7ec/5W3TP96JPPchA5ufGHQLV9ftfLyUY1Dg/FiEuf?= =?us-ascii?q?qIL+Pz6O0+QCrXSb4PB7VeKzkWEotwJxriKzyccrj4nEn4QYwU3H+yVh2Is4JM?= =?us-ascii?q?O0RFRmbdOqCpdcqi6XOohsTs8/X21luT42xqAGtJO/ZiQG1YgrywLFZ/GDc4WE?= =?us-ascii?q?+A/vWeefLDtginJqZrGyiwq3/EWlyuDxWcu530pPoydLjtbBuW4B2hnN5cSaV/?= =?us-ascii?q?Ry5EKs1iiS2A/J9O1JJ10/m7DBJJ472LEwk4IesUTdES/yn0X7lKiWdlg4+uit?= =?us-ascii?q?8evnY7HmqoKTOoJ3lw3yLqUjltalDuQlLggOX3Ob+eGg1L3750H2XLJKgucrkq?= =?us-ascii?q?naqJzaJMIbqbClAwJN04sv9QyzAyqo3dgCgHUKI1FIdAiag4T1OlzCOPX4Au2+?= =?us-ascii?q?g1Sonjdr3ffGPrj5D5rQNHjMiq7tfbBj5E9S0wo+1tVf6IxICr4bO/LzRlX+u8?= =?us-ascii?q?DbDhMjLwO0xOPnBM1n1owCQWKPHrOZMKTKvFCU/O0vJu2MaJYRuDb8MPgl++Xj?= =?us-ascii?q?jWQ5mF8YZammx4EbaHG+HvR8IkWWe2DggtkbETRCgg1rYenrjFyFZhxefOSpaI?= =?us-ascii?q?014jU2B4WRJJ3CT5vl1LGpzHfjWJpMaTYVJEqLFCLEfpuFV78lbCaJJdd52mgI?= =?us-ascii?q?T7HkTYI+zjmruRPz0KZuJemS8Sod48GwnONp7vHewElhvQd/CN6QhiTUFzktzz?= =?us-ascii?q?E4AgQu1aU6mnRTj1KK0Kx2mftdTIEB4v5VWxwmPJXfied9DoKrA16TTpKyUF+j?= =?us-ascii?q?B+6eL3QpVNtono0Lblp0AMmrhROF1C2vUedMyu67Qacs+6eZ5EDfYsZwz3GdjP?= =?us-ascii?q?smkkUjS8pLbDH23/YhsQHOG47SllmB0a2tM7kfjnbA?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAAAPGhpch2qUDT5jHQEBBQEHBQGBV?= =?us-ascii?q?AUBCwGBMCqCETGMa4sdUgaBNXyIJ45NgWcLAQEshEACgmgaBwEEMwYNAQMBAQI?= =?us-ascii?q?BAQEBARMBAQEIDQkIKS+CNiQBgmEBAQEBAgF0BQULAgEIEgYuMhcOAgQODRODB?= =?us-ascii?q?4F1BQgBAwGldxqCVIowjD+BD4EHgRFGgSptNYRpCw+DN4ImAokkEkCGJpA5Wgm?= =?us-ascii?q?KU4cOEgaRVplVAgQLAhSBXGSBFDMaI1CCbYI0gQgBDo0PgXkhinSBLAGBHgEB?= X-IPAS-Result: =?us-ascii?q?A0BYAAAPGhpch2qUDT5jHQEBBQEHBQGBVAUBCwGBMCqCETG?= =?us-ascii?q?Ma4sdUgaBNXyIJ45NgWcLAQEshEACgmgaBwEEMwYNAQMBAQIBAQEBARMBAQEID?= =?us-ascii?q?QkIKS+CNiQBgmEBAQEBAgF0BQULAgEIEgYuMhcOAgQODRODB4F1BQgBAwGldxq?= =?us-ascii?q?CVIowjD+BD4EHgRFGgSptNYRpCw+DN4ImAokkEkCGJpA5WgmKU4cOEgaRVplVA?= =?us-ascii?q?gQLAhSBXGSBFDMaI1CCbYI0gQgBDo0PgXkhinSBLAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.56,372,1539640800"; d="scan'208";a="361026706" Received: from outmail148106.authsmtp.co.uk ([62.13.148.106]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 11:15:05 +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 wBJAF4rM059412 for ; Wed, 19 Dec 2018 10:15:04 GMT (envelope-from dra-news@metastack.com) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt18.authsmtp.com. (8.15.2/8.15.2) with ESMTP id wBJAF4FT062434; Wed, 19 Dec 2018 10:15:04 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 wBJAF3ba098452 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2018 10:15:04 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 wBJAF13v008263; Wed, 19 Dec 2018 10:15:01 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 10:15:01 +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: AQHUlzj8cvOZnBA/G06CdkvKExYwhqWFyv+g Date: Wed, 19 Dec 2018 10:15:00 +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> In-Reply-To: <877eg6jos4.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: f3ca8865-0376-11e9-903a-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgESJgRNAn1U UHkJW1VcQFxxU2Jw YQpVIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFlsKGgEdFcXeHd4 YUNgEHNaWUNyOxB+ ER9cHWsDeGdjb2YC 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: 17248 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: > Hi David, >=20 > > 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. >=20 > 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. 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! :) > 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. >=20 > This approach is well-tested and understood thus I feel more confident > with it, but of course I have a Debian background. This is an apples vs oranges comparison - Debian (i.e. apt) only has to wor= ry about what apt can install. Imagine instead an apt package which has to = depend on being able to install a dependency from either yum, nix, brew, ch= ocolatey, ... oh, and they put your dependency in different combinations of= packages *and* use different version systems... oh, and on Windows, opam m= ay choose to download the C sources for GTK3 and build them (in opam)... > > 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. >=20 > What does this mean in practice? Is there some official policy [such as > the Debian Policy] to follow? I don't think there's (yet) a formally written down policy - but there is t= he 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 the= mselves to do it...) > > 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. >=20 > 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. 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. > > 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. >=20 > I don't see where the duplication is. In one case you do: >=20 > depends: [ "conf-gtk3.0" >=3D ... ] >=20 > and in the other >=20 > depext: [ "gtk3.0" >=3D ... ] >=20 > Indeed the depext repository should contain a centralized database of > depext mappings. Your centralized database literally is the conf package - it already exists= , there's no need for a change. You are proposing replacing the multiple en= tries in depext filtered by os-distribution with a single entry called gtk3= .0 and having a central repository which has the os-distribution specific m= eanings of "gtk3.0" - it's the same thing. The mistake in what you're describing is *how* it is possible to map a vers= ion constraint. > > 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? >=20 > 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. >=20 > 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". This confirms my original suspicion - the conf-gtk3 package should absolute= ly not be encoding the version test of GTK3, it should simply install it an= d just have an ultra-simple check that it works (like the other conf packag= es). In terms of the versioning problem, opam has two notions for selecting betw= een different packages - dependency and availability. Availability is thing= s about your environment (e.g. os, architecture and, prior to opam 2, OCaml= version). Availability is a static check, used to eliminate packages from = consideration by the solver. Dependency is dealt with by the solver, and re= sults in a choice between multiple *buildable/installable* packages. It mak= es no sense for conf-gtk3 to have multiple versions of the package (i.e. fo= r dependency) if you cannot actually install them - this is the problem des= cribed in the thread, but the conclusion should have been to stop trying to= put the version test in conf-gtk3, not accuse conf- packages of being a br= oken concept. What is really needed is a hybrid kind of availability test which could ind= eed be encoded as a version on the depext specification (that version check= would still need to be os-dependent). This I know is being considered alre= ady, but it is quite a large change in the solver architecture, since as fa= r I can see it either requires multi-stage solving (which is something we'v= e really tried to avoid in opam) or much deeper querying of the OS package = manager to get what is available and what could be available. Essentially, = this would generalise even further the configuration which exists to detect= your system OCaml compiler's version.=20 > > 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. >=20 > 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. In order to depend on GTK you need a notion, in opam, of what "depend on GT= K" 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 o= n GTK you depend on the conf-gtk3 package", and you no longer have to worry= about OSes beyond your own (knowledge).=20 > 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. >=20 > If they are 1:1, then the indirection seems unnecessary [at the package > level] As far as I can see, this is based on an incorrect notion of where lablgtk = should be detecting the version of GTK which is installed - it should not b= e encoded in the conf-gtk3 package, as I elaborated below... > > 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 ">=3D 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 ">=3D 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. >=20 > Well that seems even worse I'd dare to say; more coupling and more > packages is going to be worse, I think. >=20 > 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 fee= l that lablgtk3 then becomes less "self-contained". > 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] Again, duplication of depext mappings is already removed - that's what we u= se conf packages for... 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=