On Thu, Jun 19, 2008 at 04:28:28PM -0400, Adam C Powell IV wrote:
> I maintain a set of packages which depend openmpi which is missing on
> certain architectures. To get around the latter problem, I use
I've frequently a similar issues: OCaml programs compiled in bytecode
depends on C stubs to interface with C libraries, while programs
compiled in native code relies on the usual shlibs mechanism. The
dependencies on stubs should be there only on archs where the native
code OCaml compiler is not available.
My usual solution are substvars, which work nicely.
The annoying part of that solution is that I know have 2 different files
in which taking care of dependencies: control and rules (where I pass
the appropriate -V to dpkg-gencontrol).
Since apparently there are quite cases like that, what is the reason for
forbidding arch-specific dependencies in control? Can we reconsider
that? I imagine the rationale was that (arch:any) binary package stanza
are supposed to be for a single arch, but the arch-specificity of deps
can be resolved later on, for example ad build-time, preserving this
assumption. Practically it won't be much different than substvar, but
the dependency syntax would become more consistent and handy for
maintainers.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature