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
