[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to cope with bad package

  [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 .. :)


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

Reply to: