[debian-ocaml-maint CC'ed again, quoting at full for the benefit of
its subscribers.]
* John Skaller [Sun, 12 Jun 2005 20:40:09 +1000]:
> On Sun, 2005-06-12 at 10:30 +0200, Pierre Habouzit wrote:
> > Le Dim 12 Juin 2005 08:51, John Skaller a écrit :
> > > How should a package build script cope with a fault
> > > in a package used in a build?
> > > The situation: there is a fatal bug in the 'ocaml' binary
> > > package for the amd64 architecture. This package would
> > > contain the native code ocaml compiler for amd64, which
> > > has a bug. Native code compilers for x86 works.
> > > The debian/rules can detect amd64, and there is a way
> > > to force the upstream source to not use the native code
> > > compiler.
> > > However, the problem will probably be fixed, but I cannot
> > > predict in which release of Ocaml.
> > > I propose to 'hack' debian/rules to cope. Would that
> > > be the proper way?
> > could you bemore specific on the bugs you encounter ? because your
> > explanation lost me a bit.
> 1. The program 'flxg' is an Ocaml program in the Felix system,
> and is the primary executable of the Felix package. The ITP
> registration is here:
> Bug#312734: Acknowledgement (ITP: felix -- a high performance
> statically typed scripting language)
> 2. When the source code for 'flxg' is compiled by the Ocaml native code
> compiler 'ocamlopt' on the amd64 the resulting executable segfaults.
> 3. When the bytecode compiler 'ocamlc' is used to build 'flxg'
> the resulting program executes. When the native code
> compiler is used on the x86, 'flxg' works.
> 4. The choice between 'ocamlopt' and 'ocamlc' is made by
> by the upstream build system.
> 5. There is an override in the configuration script
> to force the use of the bytecode compiler.
> 6. I propose to check for 'amd64' in the debian/rules
> makefile, and call configure like this:
> ./configure --set-int-NATIVE_CODE_COMPILER=0
> if architecture 'amd64' is detected: this will stop
> the build process using the faulty native code compiler
> even if it is detected.
> Unfortunately the condition is not correct: it will
> exclude all versions of the Ocaml native code compiler
> for the amd64, even versions in which the bug is
> fixed (which I'm sure it will be). However
> (a) I don't know in which version it will be fixed
> (b) I don't know how to specify a condition on
> a particular range of versions of a package, particularly
> when the upper limit of the range is unknown at this time.
Well, why don't you just put the ./configure option there for amd64
without checking for versions, and when a version of ocaml-native-compilers
that fixes the issue gets uploaded, you re-upload your package with a
versioned build-dependency on it.
There should be a bug about this breakage on amd64, so you should be
able to find out when the issue gets closed. Also, you could submit a
bug against your own package ("ocaml-native-compilers not being used
for amd64 because of Bug#XXX), so that the need of removing that
./configure option is not forgotten.
There'd be also the option of a build-conflicts, but if the configure
option works fine, it seems best.
And yet a third option would be to remove the amd64 ocaml-native-compilers
binaries from the archive, if this breakage is known, affects all
packages, and will take a while to solve. The maintainer would know
more about this.
> (c) I cannot simplify the conditions under which the
> fault occurs, and so can't provide an 'autoconf' style
> executable test for it: at best I could 'try' the default
> build and rebuild the whole binary package from scratch
> using the bytecode compiler if build failed using the
> native code compiler .. this solution is quite general
> but extremely ugly .. this is my first attempt to make
> a Debian package and I suspect people would frown on
> this technique .. :)
Cheers,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
-- Alan Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
