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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 417F281799 for ; Wed, 24 Jul 2013 18:58:10 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of thomas.gazagnaire@gmail.com) identity=pra; client-ip=209.85.212.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="thomas.gazagnaire@gmail.com"; x-sender="thomas.gazagnaire@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of thomas.gazagnaire@gmail.com designates 209.85.212.169 as permitted sender) identity=mailfrom; client-ip=209.85.212.169; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="thomas.gazagnaire@gmail.com"; x-sender="thomas.gazagnaire@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.national.inria.fr; envelope-from="thomas.gazagnaire@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: ArUBAPEG8FHRVdSpk2dsb2JhbABagzy+MYEWFg4BAQEBBwsLCRQEJIIkAQEEAToGATgBAwELAQUFGC40AQUBHAYTh34DCQYEm0uPToRsJw2IWAEFDI8+g0xuA54CiUU/gV2CXw X-IPAS-Result: ArUBAPEG8FHRVdSpk2dsb2JhbABagzy+MYEWFg4BAQEBBwsLCRQEJIIkAQEEAToGATgBAwELAQUFGC40AQUBHAYTh34DCQYEm0uPToRsJw2IWAEFDI8+g0xuA54CiUU/gV2CXw X-IronPort-AV: E=Sophos;i="4.89,736,1367964000"; d="scan'208";a="22152479" Received: from mail-wi0-f169.google.com ([209.85.212.169]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2013 18:58:09 +0200 Received: by mail-wi0-f169.google.com with SMTP id c10so5390332wiw.4 for ; Wed, 24 Jul 2013 09:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1nP1/erNQvBTisH/qvJW3vnoLW6Rfc6dHBkEnyeXRnA=; b=HDT9sF9847jFnWNLtpYVvQRz9O86aMrxgvx5BonlNsPv3uMvl/E1xFUghoLJhmZB/z L7xDFnOcO1XIQjWA8hX8oCqULXscTXHdEAGeLIYJuldXx5t6iFRBdOEAlGbJIkVUhSd/ jKf1yvKcXaj7nYXEErHC4gahnVpplQTOpF72fs6buzf/SVZ37axFfFb8yAEstRzstOJi aHGmZp45222nbb4DPwTAMFlIY0Hs06rnK0EwYwwfyzob7PIjmRYKKmHTiHCAuMQyWMYd MP9Hq2n5jMt5FvmEIk+2Qg0e5HNK+HrcbBIPSqtPvnr31gE9iK+hIcK0+HxHWjR6O4Oz EkAA== X-Received: by 10.180.39.136 with SMTP id p8mr3446972wik.11.1374685089434; Wed, 24 Jul 2013 09:58:09 -0700 (PDT) Received: from [192.168.0.12] (gou06-3-88-170-165-56.fbx.proxad.net. [88.170.165.56]) by mx.google.com with ESMTPSA id fs8sm6649148wib.0.2013.07.24.09.58.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:58:08 -0700 (PDT) Sender: Thomas Gazagnaire Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Thomas Gazagnaire In-Reply-To: Date: Wed, 24 Jul 2013 18:58:06 +0200 Cc: Gerd Stolpmann , Fabrice Le Fessant , Francois Berenger , Ocaml Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <1D7F094E-0380-4D11-97BD-F047C57AB331@ocamlpro.com> References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> To: Markus Mottl X-Mailer: Apple Mail (2.1085) Subject: Re: AW: [Caml-list] GODI is shutting down > On Wed, Jul 24, 2013 at 12:25 PM, Thomas Gazagnaire = wrote: >> 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, mo= dify the package tarball, and make a new release -- which means you can nev= er fix constraints on already released packages. But I guess in this case, = it's fine if the _oasis and OPAM files are not in sync. >=20 > The way I see it is that a package that contains incorrect dependency > information, even if it's just a version thing, has a bug and should > be fixed. I agree this is annoying to package developers, but fixing > bugs is always annoying ;-) Unfortunately, in practice this is a nightmare as dependency constraints ar= e mostly open: when you create a new (incompatible release), you usually in= validate existing package constraint boundaries of already released package= s. For instance, let's have A, depending on B >=3D 1.0. Later you release B= version "1.1" which breaks A. Then, you need to upgrade the dependency con= straints of A to 1.0 <=3D B <=3D 1.1, ie. release a new version of A. This = can in turn force you to release new packages and so on. Cabal is dealing with that by automatically restricting the constraint boun= daries[1] and I'm not very happy with that either. -- Thomas=