From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 70D4681799 for ; Wed, 24 Jul 2013 17:58:38 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.212.169 as permitted sender) identity=mailfrom; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f169.google.com) identity=helo; client-ip=209.85.212.169; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wi0-f169.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEDAFb571HRVdSpk2dsb2JhbABbgztQwH0EAYEOCBYOAQEBAQcLCwkUBCSCJAEBBAFAARQHHQEDAQsGBQsNLiEBAREBBQEcBhOHfQEDCQabWIxPgn+EUwoZJw1kh3QBBQyNCYFQZTMHhAADlXaBaYwng0EWKYRWIA X-IPAS-Result: AnEDAFb571HRVdSpk2dsb2JhbABbgztQwH0EAYEOCBYOAQEBAQcLCwkUBCSCJAEBBAFAARQHHQEDAQsGBQsNLiEBAREBBQEcBhOHfQEDCQabWIxPgn+EUwoZJw1kh3QBBQyNCYFQZTMHhAADlXaBaYwng0EWKYRWIA X-IronPort-AV: E=Sophos;i="4.89,736,1367964000"; d="scan'208";a="27185298" Received: from mail-wi0-f169.google.com ([209.85.212.169]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2013 17:58:21 +0200 Received: by mail-wi0-f169.google.com with SMTP id c10so5316816wiw.2 for ; Wed, 24 Jul 2013 08:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=txnDra6zl36e6IuJCaWCn05EOODsBkk0B/Kr58EfeLo=; b=SixLLS0ce7BcpBg8nEgPVLZhTIR9Oy4smWHXmJYCp0oC1snDs+MYiluh8ozOQgfmt0 Wx2sRtr6ar5Cif/ZM5k3anKJlVEcDZDjazt0UIiM9cHQ1tf3chbc42oeiLv3NMmUv3OA JN8l2o8bsjAqYTz307bdo6NVHiKvWCZecL4OHVl2th2otWWxjNgrIgtfmx0H66QlkgbX VPky/vyzVnrWUCncQoE/vJ5Iw3xMo+PIhL60gyhOGDVuDlVrR2ugPwzdqx6ngeycp3aT Vsf0zQ2gnvVJjGq2/Rl5LZ2HNsc6Po/HEIAwAEGtGURHRms5Ummq3Fb9e2GXLhGnNh5+ lLkA== MIME-Version: 1.0 X-Received: by 10.194.122.103 with SMTP id lr7mr27445296wjb.15.1374681501720; Wed, 24 Jul 2013 08:58:21 -0700 (PDT) Received: by 10.194.172.169 with HTTP; Wed, 24 Jul 2013 08:58:21 -0700 (PDT) In-Reply-To: <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> Date: Wed, 24 Jul 2013 11:58:21 -0400 Message-ID: From: Markus Mottl To: Thomas Gazagnaire Cc: Gerd Stolpmann , Fabrice Le Fessant , Francois Berenger , Ocaml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: AW: [Caml-list] GODI is shutting down On Wed, Jul 24, 2013 at 10:44 AM, Thomas Gazagnaire w= rote: > 6. "No, all package managers should unite in this point, and only accept > packages with oasis support. (Btw, that's homework for me.) Just do it the > same way as we did when requiring findlib." > > I disagree, people should be free to use whatever system they want. Let me add here that avoiding limitations or obstacles does not necessarily create more freedom. I, as a package developer, want to have the freedom of not having to worry about annoyances in the packaging process that are only there so that unlikely alternatives can be supported. Lets keep the simple (=3D standard) things simple while keeping the non-standard things possible, but I'd prefer simplicity if there is a conflict. Oasis may are may not become the standard OCaml package specification tool, but it is widely used so I think it's fair if it is better supported by OPAM than alternatives. > 7. About the generation of OPAM files from _oasis > > I am not totally convinced by all the arguments I seen so far. Making a n= ew release because a package constraint is wrong seems not to be a good ide= a to me. A large proportion of pull request in the the package metadata's r= epository is about fixing such dependency constraints (which are discovered= by our testing tools). I don't have a yet a good story to bring that infor= mation back into the package, but I'd say that I'm not very fond of mixing = everything together: let's keep the dependency constraints part of the pack= age system and the build instruction part of the build system -- that's muc= h simpler that way. It's funny that you say that, because this collides with your opinion on 6). This would mean forcing people to use OPAM to specify package version dependencies instead of leaving this information in their packages. That's why I think that requiring (or at least well-supporting) something like Oasis package specifications as standard adds freedom for package developers. My guess is that you are not totally happy with Oasis at this point so this may be a topic to address. Being an Oasis user, I would say that the Oasis tools may not be as mature yet as one would hope, but the Cabal-like package specification syntax seems decent enough to be supported by OPAM. It really shouldn't be that hard to automate the process of updating OPAM metadata (including version constraints) based on changes in Oasis package specifications. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com