On Tue, 2005-03-22 at 14:24 -0600, Adam Heath wrote: > On Fri, 18 Mar 2005, Scott James Remnant wrote: > > > > So there are three possibilities: > > > > > > * dpkg 1.10.11 did not add support for arch-specific entries in > > > *Depends* and closing 170575 with dpkg 1.10.11's changelog was an > > > error. > > > > > From what I can tell, this is correct. Support for per-arch BUILD > > dependencies was added, not general dependencies. > > Wrong. You can have per-arch *regular* depends. dpkg-gencontrol just strips > out the tokens that don't apply for the current arch. > parsedep() in controllib.pl supports it, and the same function is used by both the build-depend and depend parsers. However it only checks for the "[...]" part if $use_arch (the second argument) is true and only removes dependencies that don't match if $reduce_arch (the third argument) is also true. dpkg-checkbuilddeps.pl always sets both arguments to true, so it supports [...] syntax for build dependencies and removes dependencies that don't match the host architecture. dpkg-gencontrol.pl doesn't pass any second or third argument, so they default to undef which is false. This means that for the other dependency fields, [...] syntax isn't supported and dependencies for other architectures are not removed. Changing this would be a simple matter of adding ", 1, 1" to the parsedep() call in dpkg-gencontrol, however this sets a precedence that (other than substvars) the dependency lines in debian/control won't necessarily match those in DEBIAN/control -- I don't know if we want to do that or not yet. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part