On 2013-10-25 11:55, Stéphane Glondu wrote:
> Le 24/10/2013 08:27, Niels Thykier a écrit :
>> Your package has out of date binaries on architectures were
>> ocaml-estring is unavailable (e.g. armhf), but it appears to have
>> built there in the past. This is a blocker for ocaml-sqlexpr
>> migrating to testing[1].
>> If ocaml-sqlexpr should no longer be built on these architectures,
>> then please reassign this bug to ftp.debian.org and request them to
>> remove the binaries on the affected architectures.
>
> Why has this bug been reported against ocaml-sqlexpr? The problem boils
> down to ocaml-estring failing to build on some architectures...
>
>
> Cheers,
>
One solution would be to fix ocaml-estring, so it builds on these
architectures. However, ocaml-estring has "no obligation"[1] to be
built on these architectures, since it was never built on these in the past.
However, ocaml-sqlexpr built on these architectures in the past, so it
has an obligation to build there again. But ocaml-sqlexpr picked up an
unconditional Build-Dependency on ocaml-estring, which means it can no
longer be built on these architectures. This is why I filed this bug
against ocaml-sqlexpr.
This means there are (basically) 3 solutions to this problem:
1 make ocaml-estring build on these architectures.
2 make ocaml-sqlexpr's build-depends on ocaml-estring conditional
(i.e. limit it to architectures where ocaml-estring is available)
3 retire support for architectures without ocmal-estring and reomving
the obligation to be built on these architectures for now.
To be honest, I do not really care which solution you go with. I just
want a new version of ocaml-sqlexpr to migrate to testing (as it fixes
#718138).
You are welcome to claim that it is "reasonably possible" for
ocaml-estring to support these architectures and therefore this is a bug
in ocaml-estring.
However, I am pretty sure you need to convince the maintainer to
accept this or he/she can simply downgrade it to wishlist (possibly with
a wontfix tag) and ocaml-sqlexpr would remain RC buggy. However, given
the maintainer is the same in this case, I doubt this will be a problem.
~Niels
[1] http://release.debian.org/jessie/rc_policy.txt
"""
4. Autobuilding
[...]
Packages must autobuild without failure on all architectures on
which they are supported. Packages must be supported on as many
architectures as is reasonably possible. Packages are assumed to
be supported on all architectures for which they have previously
built successfully. Prior builds for unsupported architectures
must be removed from the archive (contact -release or ftpmaster
if this is the case).
"""
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
