Am Freitag 05 Februar 2010 09:04:45 schrieb Tollef Fog Heen:
> | #get the location of the .pc file
> | PC_NONOPTS=`echo $@ | sed -e 's/(--[^ ]* )*//g'`
> | PC_FILEDIR=`pkg-config --variable=pcfiledir "$PC_NONOPTS"`
> | PC_RESULT=$?
> | test "$PC_FILEDIR" || exit $PC_RESULT
>
> This one is not, it won't work at all.
>

It does, at least for my use-case of pkg-config.

Though I agree that this is not needed for you (only for relocation of
libraries). But still, one simple wrapper is enough to support multiarch
library dirs.

HS


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

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.

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.

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.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le mercredi 03 février 2010 Ã* 10:48 +0100, Goswin von Brederlow a
écrit :
> > If we want to support multiarch compilation, this sounds ok to me. I'm
> > personally not convinced by the point of doing it. Though.
>
> We probably don't want multiarch compilation as such but cross
> compilation is a huge benfit for many people and multiarch dev packages
> would make it possible to cross compile without having to set a sysroot
> and without mangling packages during unpacking.

Cross-compiling packages without a dedicated build root sounds like a
very, very bad idea to me.

> It also makes sense to compile sources with everything in the triplet
> dir. No point having the *.so link or .pc files in different libdirs. It
> is probably harder to not multiarchify the -dev packages as well.

It is only marginally harder to make the .so symlink point to the .so.N
in the arch-triplet directory. It is just the same as what is done
with /lib.

--
.'`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things� -- Jörg Schilling

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
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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Josselin Mouette <joss@debian.org> writes:

> Le mercredi 03 février 2010 Ã* 10:48 +0100, Goswin von Brederlow a
> écrit :
>> > If we want to support multiarch compilation, this sounds ok to me. I'm
>> > personally not convinced by the point of doing it. Though.
>>
>> We probably don't want multiarch compilation as such but cross
>> compilation is a huge benfit for many people and multiarch dev packages
>> would make it possible to cross compile without having to set a sysroot
>> and without mangling packages during unpacking.
>
> Cross-compiling packages without a dedicated build root sounds like a
> very, very bad idea to me.

The design of multiarch is so that you can install the arm deb on arm
and compile or unpack it into a chroot and cross-compile or even install
it in your real system and cross-compile there.

The big change will be that you no longer need to compile a bunch of
cross compile libraries but you can just use the debian packages as is.

Also you probably want a build chroot. In there you need the native libs
and tools and a cross-compiler. Do you then want to have a chroot in the
chroot for the foreign libs? Or a single multiarch chroot for the native
tools, cross-compiler and foreign libs?

>> It also makes sense to compile sources with everything in the triplet
>> dir. No point having the *.so link or .pc files in different libdirs. It
>> is probably harder to not multiarchify the -dev packages as well.
>
> It is only marginally harder to make the .so symlink point to the .so.N
> in the arch-triplet directory. It is just the same as what is done
> with /lib.

Setting the link different is simple. But then you need to edit the .pc
file as well. It adds up.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org