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 A64E281799 for ; Wed, 24 Jul 2013 19:33:07 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAKkO8FGwCYo3/2dsb2JhbABagmUhvmeBFhZ0giQBAQVAAQE2Ag8LGAkWDwkDAgECAUUTBgICiA0DpleEQgEFjXQGkAQWg2qJJ447kU2DFw X-IPAS-Result: AiQFAKkO8FGwCYo3/2dsb2JhbABagmUhvmeBFhZ0giQBAQVAAQE2Ag8LGAkWDwkDAgECAUUTBgICiA0DpleEQgEFjXQGkAQWg2qJJ447kU2DFw X-IronPort-AV: E=Sophos;i="4.89,736,1367964000"; d="scan'208";a="27196955" Received: from mail.etorok.net ([176.9.138.55]) by mail2-smtp-roc.national.inria.fr with ESMTP; 24 Jul 2013 19:33:07 +0200 Received: from [IPv6:2a02:2f09:4080:e700:acf0:c5d8:3b09:94be] (unknown [IPv6:2a02:2f09:4080:e700:acf0:c5d8:3b09:94be]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.etorok.net (Postfix) with ESMTPSA id 0229A46D8 for ; Wed, 24 Jul 2013 19:33:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=mailout; t=1374687186; bh=8YZVQ14XnwkUFENnW7Wpl7Db7yLffvQLlUvZqbcHb70=; l=1909; h=Date:From:To:References:In-Reply-To:From; b=FhxG76HVe/tlczxSmX+u1AL75uQ8OvniSwpv1y1PtA6RIoiSeavShkPc0ukyDy2Xl g//afZsOKLIxth8X2hBiFhIEXnn9/IhonZ3pw5Nitcd5n7lLI801PGhMlauacM5aNa svIyKHQEyuKMUk9K6S6KSoqxWmzFBD17wYM6w6rg= Message-ID: <51F00FD0.9090402@etorok.net> Date: Wed, 24 Jul 2013 20:33:04 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: caml-list@inria.fr References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> <1D7F094E-0380-4D11-97BD-F047C57AB331@ocamlpro.com> In-Reply-To: <1D7F094E-0380-4D11-97BD-F047C57AB331@ocamlpro.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: AW: [Caml-list] GODI is shutting down On 07/24/2013 07:58 PM, Thomas Gazagnaire wrote: >> 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, modify the package tarball, and make a new >>> release -- which means you can never 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. >> >> 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 are mostly open: when you create a new (incompatible > release), you usually invalidate existing package constraint > boundaries of already released packages. For instance, let's have A, > depending on B >= 1.0. Later you release B version "1.1" which breaks > A. That is a bug in package B, and should be addressed before making v1.1 available in the main repository: 1) either update version constraints of A as you suggest directly in opam 2) fix package B to be backwards compatible (or at least report a bug upstream about it) 3) do as in #1, i.e. use opam file as authoritative source, but report a bug against package A with a patch to _oasis, and a request to regenerate the files. The bugreport could even be automated (I assume package maintainers are automatically notified of bugs in their packages as well?) There is also the possibility to automatically run 'oasis setup' for usual packages (that don't need special OASIS plugins and so on), and include the generated files as patches ... automatically. --Edwin