Re: Multiarch and ABI support
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.
> 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
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
Reply to: