caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sven Luther <sven.luther@wanadoo.fr>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>,
	zack@debian.org, caml-list@inria.fr,
	debian-ocaml-maint@lists.debian.org
Subject: Re: [Caml-list] binary compatibility of 3.08.3
Date: Sun, 16 Jan 2005 14:37:25 +0100	[thread overview]
Message-ID: <20050116133724.GB1467@pegasos> (raw)
In-Reply-To: <20050115120719.GB11037@yquem.inria.fr>

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


  reply	other threads:[~2005-01-16 13:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13  7:24 [Caml-list] Bug in Unix library on Mac? spiral voice
2005-01-13 16:53 ` Damien Doligez
2005-01-13 18:41   ` binary compatibility of 3.08.3 Stefano Zacchiroli
2005-01-13 23:02     ` [Caml-list] " Jacques Garrigue
2005-01-14 13:36       ` Sven Luther
2005-01-14 15:01         ` Yaron Minsky
2005-01-16 13:25           ` Sven Luther
2005-01-16 13:33             ` Berke Durak
2005-01-16 14:31               ` Sven Luther
2005-01-17  5:52             ` William Lovas
2005-01-15 12:07         ` Xavier Leroy
2005-01-16 13:37           ` Sven Luther [this message]
2005-01-16 16:26             ` Jacques Garrigue
2005-01-16 18:23               ` Sven Luther
2005-01-20  5:53                 ` Jacques Garrigue
2005-01-20  8:59                   ` Sven Luther
2005-01-16 21:08             ` Damien Doligez
2005-01-16 22:27               ` Sven Luther
2005-01-14 15:25       ` Marcin 'Qrczak' Kowalczyk
2005-01-27 15:40       ` Christophe TROESTLER
2005-01-30  6:11         ` Sven Luther
2005-01-30 11:12           ` Christophe TROESTLER
2005-01-30 15:28           ` Stefan Monnier
2005-01-31  7:09             ` Sven Luther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050116133724.GB1467@pegasos \
    --to=sven.luther@wanadoo.fr \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=debian-ocaml-maint@lists.debian.org \
    --cc=garrigue@math.nagoya-u.ac.jp \
    --cc=zack@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).