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 9648A81799 for ; Wed, 24 Jul 2013 18:37:11 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.41 as permitted sender) identity=mailfrom; client-ip=209.85.214.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-bk0-f41.google.com) identity=helo; client-ip=209.85.214.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQBAMMB8FHRVdYpk2dsb2JhbABagztQqziSKoEOCBYOAQEBAQcLCwkUBCSCJAEBBAFAARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEgmHYgEDCQYMmziMT4J/hE0KGScDCmSHdAEFDI8+MweEAAOXX4Epjj8WKYQ8Og X-IPAS-Result: AtQBAMMB8FHRVdYpk2dsb2JhbABagztQqziSKoEOCBYOAQEBAQcLCwkUBCSCJAEBBAFAARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEgmHYgEDCQYMmziMT4J/hE0KGScDCmSHdAEFDI8+MweEAAOXX4Epjj8WKYQ8Og X-IronPort-AV: E=Sophos;i="4.89,736,1367964000"; d="scan'208";a="27190690" Received: from mail-bk0-f41.google.com ([209.85.214.41]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2013 18:37:10 +0200 Received: by mail-bk0-f41.google.com with SMTP id jc3so271774bkc.14 for ; Wed, 24 Jul 2013 09:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hDTL+ewI1tzVhrpivkJAEehVoyBxsW3aQ9rOwN7DPlU=; b=JwrTmBrqX5FKAIgnzz52i6TZQvu0tk15/2/UzbTdMXKg6k+3vRodJV/cEpHaGfl2UL xYOVqtzRbZ8UErwE0DtPDKAHX18Jd5pSDzKjrZCnxCOxyUMTG9Zz5bCr+XkCIxSZ3wpl PHhvjq6TI6k2mcZJHDqGPFEdw067i9Jwc7HKcDh0hAop/fM7sZfvrk3hgHXKWEyvowkB RDFQnkW7kRyQm0sjY6wkkNbuQPirmVUR2kdDBt6V48O6+ne8B/w+V3n2xFWYUskuaYzi xtu6gi12xcKV7oQtSgzL5kTnJ6xzxXVgUsGQcwo0Re3jb5WoF3XBzqytADgByK1fcg2D zUiA== X-Received: by 10.204.76.141 with SMTP id c13mr5586984bkk.42.1374683830451; Wed, 24 Jul 2013 09:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.20.131 with HTTP; Wed, 24 Jul 2013 09:36:30 -0700 (PDT) In-Reply-To: References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> From: Gabriel Scherer Date: Wed, 24 Jul 2013 18:36:30 +0200 Message-ID: To: Thomas Gazagnaire Cc: Markus Mottl , 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 > However, the main problem (the one I wanted to point out) still remains: = every time you want to fix a constraint you have to change your _oasis, mod= ify the package tarball, and make a new release -- which means you can neve= r fix constraints on already released packages. But I guess in this case, i= t's fine if the _oasis and OPAM files are not in sync. You could include a patch against the _oasis file in the OPAM (or GODI) metadata. On Wed, Jul 24, 2013 at 6:25 PM, Thomas Gazagnaire wr= ote: >> 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. > > Right, this is indeed a feature requested by many people, than I can hear= . This is tracked and discussed in [1] and I'm fine to try to implement the= proposed solution in 1.1 (I've just updated the issue's release target). > > [1] https://github.com/OCamlPro/opam/issues/156 > >> 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. > > A substantial amount of work has already been done by Christophe Troestle= r to automate the conversion of _oasis into OPAM files: > > $ opam install oasis2opam > > I'm sure this can be completed to automate the pull-request machinery as = well. > > However, the main problem (the one I wanted to point out) still remains: = every time you want to fix a constraint you have to change your _oasis, mod= ify the package tarball, and make a new release -- which means you can neve= r fix constraints on already released packages. But I guess in this case, i= t's fine if the _oasis and OPAM files are not in sync. > > [2] https://github.com/ocaml/oasis2opam > > -- > Thomas > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs