From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D20A5BC8C for ; Sun, 16 Jan 2005 14:37:59 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0GDbxWw008151 for ; Sun, 16 Jan 2005 14:37:59 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA14857 for ; Sun, 16 Jan 2005 14:37:58 +0100 (MET) Received: from smtp3.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.28]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0GDbw5p021425; Sun, 16 Jan 2005 14:37:58 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0312.wanadoo.fr (SMTP Server) with ESMTP id 1CC581C0010F; Sun, 16 Jan 2005 14:37:55 +0100 (CET) Received: from pegasos (AStrasbourg-251-1-58-54.w82-126.abo.wanadoo.fr [82.126.136.54]) by mwinf0312.wanadoo.fr (SMTP Server) with ESMTP id 7148B1C0011A; Sun, 16 Jan 2005 14:37:52 +0100 (CET) Received: from luther by pegasos with local (Exim 4.34) id 1CqAat-0000PA-OC; Sun, 16 Jan 2005 14:37:27 +0100 Date: Sun, 16 Jan 2005 14:37:25 +0100 To: Xavier Leroy Cc: Jacques Garrigue , zack@debian.org, caml-list@inria.fr, debian-ocaml-maint@lists.debian.org Subject: Re: [Caml-list] binary compatibility of 3.08.3 Message-ID: <20050116133724.GB1467@pegasos> Mail-Followup-To: Xavier Leroy , Jacques Garrigue , zack@debian.org, caml-list@inria.fr, debian-ocaml-maint@lists.debian.org References: <99C2C114-6583-11D9-B72B-000D9345235C@inria.fr> <20050113184137.GA24040@fistandantilus.takhisis.org> <20050113.150239.95895778.garrigue@math.nagoya-u.ac.jp> <20050114133632.GA4923@pegasos> <20050115120719.GB11037@yquem.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20050115120719.GB11037@yquem.inria.fr> User-Agent: Mutt/1.5.6+20040907i From: Sven Luther X-Miltered: at concorde with ID 41EA6E37.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41EA6E36.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 binary:01 sven:01 luther:01 sven:01 luther:01 wrote:01 bugfix:01 ocaml:01 arches:01 ocaml:01 debian's:01 messes:01 bug:01 binary:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_BL_SPAMCOP_NET autolearn=disabled version=3.0.0 X-Spam-Level: * On Sat, Jan 15, 2005 at 01:07:19PM +0100, Xavier Leroy wrote: > Sven Luther writes: > > > Notice that this is really not nice for a bugfix release, since this means we > > have to rebuild all of the ocaml related packages on all arches, which may > > take us month and such. > > I find this figure surprinsing. Compiling the whole of GODI (which > contains roughly the same number of packages as Debian OCaml) doesn't > take months, more like one hour. I know Debian has many architectures > and many of them are underpowered, but maybe that simply suggests that > Debian's dedication to supporting dead architectures is questionable. Well, this is understandable, since GODI builds in a isolated way, on one architecture, without any dependency on the result of the autobuilder. There is at least one day lag between each package build, and then there is the problems of some packages not really maintained by the debian/ocaml core team, which we may miss, or other unrelated problem in some random library or toolchain component which may bring a delay to a much needed build. And no, m68k is by far not the major problem here, ia64 and arm had much more troubles with the 3.07 to 3.08 transition, but i doubt you are suggesting debian should drop support for those ? Also, we are hoping to release soon, and the debian release manager will assuredly not wait for ocaml stuff to rebuild if it is the only thing missing. The release delay have hurt enough as it is. > > Maybe we would be better off just backporting the > > non-breaking fixes ? > > Identifying those fixes would take you and the other Debian > maintainers an awful lot of time, and in the end you'd get something > that doesn't match any "official" release from us, which is something > that I'd rather avoid (it messes up bug reporting, for one thing). Just forgetting about the fix and include it in the next version of sarge is the only sane possibility then. > > Maybe in future this situation could be somewhat improved ? > > On the Debian side, perhaps :-) On the Caml side, I don't feel like Bah. There are improvement possible, sure, in the autobuilder setup, and with the api-version management used for the ocaml packages, but it has served us well upto now, until it horribly broke with unannounced and unexpected binary brokeness in 3.08.2. > going out of my way to increase binary compatibility, which has never > been one of our design goals. Well, if binary compatibility could be maintained at least on the bug fix branch, it would be good already. But if what Jacques says is true, and the binary compatibility is only broken by the way the diggests are calculated, maybe there may be a solution there ? Or is the binary-compatibility breakage really needed ? Anyway, it would be nice if the breakage would at least be announced in the release documentation. Especially if it doesn't touch all the modules and libraries, as was the case for 3.08.2. Friendly, Sven Luther