Bug#562606: FTBFS: unknown options to dh_ocaml
Jan Wagner wrote:
> On Friday, 29. January 2010, Mehdi Dogguy wrote:
>> Jan Wagner wrote:
>>> I stumbled upon the same problem on backporting. From my point of view,
>>> user of you package don't have the track down the versioned build-dep of
>>> the packages.
>> From my point of view, users should not backport packages. We didn't
>> release dh_ocaml 0.9 for lenny, I'm pretty sure of that.
>
> Who should do backports in your eyes? Debian Developers? Maintainers? Nobody?
Certainly, not users. And, let's make that clear: it's not "in my eyes".
Ask other DDs or DMs about this particular question if you want to have
another opinion. At least, ask the usual maintainer for review before
proposing a backport. Doing otherwise seems wrong to me (unless you are
very confident with the code).
> Anyways ... you should provide correct (build-)dependencies, even if it would
> be better, if debhelper would provide a way to define such versioned dep for
> its own.
>
We already provide correct build-dependencies. Here, the only missing
thing is that our dh_ocaml uses features from debhleper 7.1.0. The
package dh-ocaml do not contain only the dh_ocaml script and ocaml
sequence, but also some other dev-tools. I see two solutions:
- Make dh-ocaml depend on debhelper >= 7.1.0 (the exact version that
introduced the desired feature). But, I'm not really convinced that this
is the right solution because we may use all what dh-ocaml ships but
dh_ocaml.
- Make dh-ocaml conflicts with debhelper << 7.1.0. But this solution
seems also wrong for the same reason I mentioned before.
If you have a better/real solution, please share with us.
If not, I will not accept any of the solutions I've mentioned because
the problem arises *only* for the backport.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
Reply to: