Peter Samuelson <pe...@p12n.org> writes: > [Goswin von Brederlow] >> Then installing the i386 package on amd64 would create the symlink >> and make sources building for 64bit find the 32bit libraries. Verry >> bad idea.
You completly missed the point. > 1) People shouldn't be installing -dev packages from the wrong > architecture. It is too early in the game to rely on that sort of > thing yet. The point was to make the -dev package multiarch. That means installable for multiple architectures. While that is not a priority we were thinking ahead. 2) If some source package does not express a Build-Depends in such a > way as to cause the correct architecture "foo-dev" package to be > installed, I'd say that's a serious bug in either the source package, > or the multi-arch design. The source Build-Depends on foo-dev and pkg-config. The problem is that a multiarch foo-dev then only works with a multiarch pkg-config. Normaly that would mean foo-dev Depends: pkg-config (>= ver). But foo-dev does not depend on pkg-config as use of pkg-config is totaly optional. So foo-dev can express that version requirement on pkg-config other than Conflicts or Breaks. And adding that to (most) -dev packages would be ugly. > 3) The dh_makeshlibs postinst logic _could_ only create the symlink if > the architecture is the host architecture, however you detect that in > multi-arch land. And indeed it could stop doing so if it detects that > pkg-config is an appropriate version. Not everyone uses dh_makeshlibs and I would rather not see that logic in postinst scripts at all. That is the sort of thing multiarch was designed to not need. It is probably fine to fix pkg-config now and then later, maybe after squeeze, just assume it is new enough. Any early adopters that want to test multiarch -dev packages (in experimental) now can use Breaks. The -dev packages are not a high priority, unlike the libs themself, so there is time for a clean transition. That would only bother old-stable backports then. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org