[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiarch and pkg-config

Peter Samuelson <peter@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

> 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.


Reply to: