Re: Multiarch and ABI support
Hector Oron <hector.oron@gmail.com> writes:
> Hi Goswin,
>
>>>> It wouldn't. I don't see a compelling reason for dpkg to do this at all.
>>>> Your quote shows that dpkg *does* do this today, which I didn't remember
>>>> before this conversation, but that's not an explanation for *why* it does
>>>> -
>>>> as opposed to dpkg directly recording what its current architecture is.
>>>
>>> I am not `dpkg' maintainer, nor I did such change, so *why* it does
>>> that I do not know, but surely there is a reason which stands valid or
>>> it is outdated.
>>
>> Compiling dpkg on a system that has no dpkg. No dpkg-architecture to get
>> the current architecture from.
>
> Sounds like a reason. Thanks.
>
>> /sysroot/usr/lib/ is the normal directory.
>> /sysroot/usr/lib/<triplet> is the multiarch directory under a sysroot
>>
>> Are you thinking of the special case of multiarch with sysroot=/?
>
> Yes, I was thinking that but later I realized that does not fit. Where
> do you place cross built binaries? It could work as build this armel
> binary and upload it to target device, but it will not work for cross
> building a small rootfs (uclibc+busybox) with in host system and then
> export it to target device or roll a tarball.
Obviously you won't be able cross-build a bash and install it in /. But
you can build all the debs for a rootfs and then debootstrap
--first-stage them, boot that as NFS root and run the second stage on
the target. Or use qemu to emulate the target architecture.
But that is the standard problem of not being able to run maintainer
script when cross creating a rootfs. I don't see where sysroot comes
into this.
>> What is wrong with the path is that the triplet is not unique and
>> sometimes differs when it shouldn't. So instead of the triplet use a
>> different string that uniquely identifies the abi. In the past the
>> triplet has just been the standard for that.
>>
>> Could I suggest dpkg-architecture -qDEB_HOST_ABI? The string should only
>> be hardcoded in one single spot.
>
> I think there is yet another proposal waiting on the pipeline to be
> proposed publicly.
>
> Cheers,
> --
> Héctor Orón
There is. The hints dropped so far though indicate that its only to fix
the <triplet> into something better fitting. As said before in this
thread it really doesn't matter what you call it or what is used in the
end. The idea of /usr/lib/<something unique>/ remains and the actual
string used doesn't change the implementation needed, just the string.
It might be better to call it a refinement of the existing proposal than
to risk people thinking they are competing proposals. At least until
there actualy is one.
MfG
Goswin
Reply to: