Sean Whitton <spwhitton@spwhitton.name> writes:
> Hello,
>
> On Sat 20 Sep 2025 at 03:57pm -07, Xiyue Deng wrote:
>
>> I should have explained the root cause in the first paragraph. Or is
>> there anything still unclear?
>
> Right, sorry.
>
> I meant that, switching to arch:any is a workaround, so there is some
> limitation of one of the relevant packaging tools you are working
> around, so it would be worth figuring out if that issue could be fixed,
> instead, before abusing arch:any.
>
> I understand why DEB_HOST_MULTIARCH would be amd64 for an arch:all
> package, I think, but I don't know the background of how the
> DEB_HOST_MULTIARCH variable is being used in this package, but it seems
> like not using that variable would be a better solution.
>
Ah I see. I sort of understand the reason behind using
DEB_HOST_MULTIARCH which is to conform to the FHS variant in Debian:
shared libraries used by other binaries (in our case `emacs' under
/usr/bin) should be installed under /usr/lib in general, and Debian's
multi-arch diverges[1] from FHS that it recommends
/usr/lib/<arch-triplet> over /usr/lib{,64,32}. I think Debian's variant
is better than as defined in FHS because it enables supporting more ABI
variations on the same host, e.g. i386 and x32 binaries under amd64
host, and maybe more variants on other architectures. So AIUI we are
following the Debian Policy requirements correctly in this case.
> --
> Sean Whitton
[1] https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure
--
Regards,
Xiyue Deng
Attachment:
signature.asc
Description: PGP signature