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 14CA4BC8C for ; Sun, 16 Jan 2005 15:31:42 +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 j0GEVf0j014122 for ; Sun, 16 Jan 2005 15:31:41 +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 PAA14818 for ; Sun, 16 Jan 2005 15:31:40 +0100 (MET) Received: from smtp1.wanadoo.fr (smtp1.wanadoo.fr [193.252.22.30]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0GEVerq026817 for ; Sun, 16 Jan 2005 15:31:40 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0104.wanadoo.fr (SMTP Server) with ESMTP id 6FC501FFFFA7; Sun, 16 Jan 2005 15:31:40 +0100 (CET) Received: from pegasos (AStrasbourg-251-1-58-54.w82-126.abo.wanadoo.fr [82.126.136.54]) by mwinf0104.wanadoo.fr (SMTP Server) with ESMTP id 10BF11FFFFB0; Sun, 16 Jan 2005 15:31:40 +0100 (CET) X-ME-UUID: 20050116143140687.10BF11FFFFB0@mwinf0104.wanadoo.fr Received: from luther by pegasos with local (Exim 4.34) id 1CqBQn-0007JP-Pr; Sun, 16 Jan 2005 15:31:05 +0100 Date: Sun, 16 Jan 2005 15:31:03 +0100 To: Berke Durak Cc: yminsky@cs.cornell.edu, 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: <20050116143103.GA28018@pegasos> Mail-Followup-To: Berke Durak , yminsky@cs.cornell.edu, 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> <891bd33905011407017d58a116@mail.gmail.com> <20050116132529.GA1467@pegasos> <20050116133308.GP4370@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20050116133308.GP4370@free.fr> User-Agent: Mutt/1.5.6+20040907i From: Sven Luther X-Miltered: at concorde with ID 41EA7ACD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41EA7ACC.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 berke:01 durak:01 wrote:01 wrote:01 yaron:01 minsky:01 ocaml:01 dependencies:01 mips: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 Sun, Jan 16, 2005 at 02:33:09PM +0100, Berke Durak wrote: > On Sun, Jan 16, 2005 at 02:25:29PM +0100, Sven Luther wrote: > > On Fri, Jan 14, 2005 at 10:01:00AM -0500, Yaron Minsky wrote: > > > It's worth mentioning that the pain of such upgrades is considerably > > > reduced by the use of a package manager like GODI. It's hardly > > > perfect, but it makes such things much easier. > > > > We already have a package manager, thank you all the same. The user won't see > > a thing, but it is a hard thing for us debian package maintainers to rebuild > > all packages that are dependent on ocaml on all 11 officially supported debian > > architectures, and a bunch of unofficial ones, especially given the fact that > > there are many dependencies, and there is at least one day lag in the > > dependency chain building, and that some of our architectures are real slow to > > build (m68k, mips/mipsel and s390 are the usual blockers, often arm and hppa > > too). And so near to the sarge release, it is a real question if we should > > forego the 3.08.3 changes or launch such a wide rebuild, which may miss the > > freeze/release date anyway, or worse even, may make some important part of the > > packages not being in the release at all. Luckily no ocaml package is part of > > base/standard, and not affected by the base freeze. > > By the way, is m68k/s390/etc. stuff built on m68k/etc. ? Why not > cross-compile on fast CPUs ? As said, we have enough m68k autobuilder to do the work, so why go for more complicated and error-prone setups. As said, during the last transition, it was not really m68k which was the problem. Friendly, Sven Luther