Re: AW: [Caml-list] GODI is shutting down

["Török Edwin" <edwin+ml-ocaml@etorok.net>]

On 07/24/2013 07:58 PM, Thomas Gazagnaire wrote:
>> On Wed, Jul 24, 2013 at 12:25 PM, Thomas Gazagnaire
>> <thomas@ocamlpro.com> 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