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 [EMAIL PROTECTED],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
signature.asc
Description: Digital signature
