(Forwarding to BTS because I missed the CC originally) ---------- Forwarded message ---------- From: Alex Willmer <[email protected]> Date: 11 February 2016 at 21:25 Subject: Re: Bug#814430: dpkg: please define cloudabi architecture To: Guillem Jover <[email protected]>
On 11 February 2016 at 18:22, Guillem Jover <[email protected]> wrote: > On Thu, 2016-02-11 at 14:34:27 +0000, Alex Willmer wrote: >> [1] https://lists.debian.org/debian-mentors/2016/02/msg00126.html > > Great! I see it already covers most of the points in > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_a_new_dpkg_architecture.3F> Thank you :) I swear I looked for such a document, sorry I missed it. > but I've got some inguiries. > (I've done some updates there just now. :) By my reading CloudABI currently falls foul of "nor it should expose it as unknown in the GNU triplet names". Are you saying the GNU triplet returned by GNU config should be changed from x86_64-unknown-cloudabi? >> --- ostable 2015-11-26 23:53:38.000000000 +0000 >> +++ ostable 2016-02-09 14:30:44.000000000 +0000 >> @@ -37,3 +37,4 @@ >> uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi >> uclibc-uclinux uclinux-uclibc >> uclinux[^-]*(-uclibc.*)? >> tos-mint mint mint[^-]* >> +cloudabi-unknown unknown-cloudabi unknown[^-]*-cloudabi > > Oh so this means the same binary could be run on FreeBSD, Linux, the > Hurd, etc. (as long as the system has been ported to support those > executables? Nice. Correct, for a given CPU a cloudabi binary should run regardless of the underlying kernel. > (BTW this reminds me a bit of my GNU/Any proposal! > <https://www.hadrons.org/~guillem/debian/ports/gnu-any/debian-gnu-any.txt> :) Nice I'll take a look > In any case I assume the unkwown here is referring to the vendor? Such > as «pc» or similar, instead of the kernel? In which case this should > not be present at all. I believe it is the vendor field. Which if I understand you (and the updated FAQ) would make the ostable addition # <Debian name> <GNU name> <config.guess regex> cloudabi-none cloudabi cloudabi[^-]* and the triplettable addition # <Debian triplet> <Debian arch> # cloudabi-none-<cpu> cloudabi-<cpu> since cloudabi is "kernel independent". Finally, to avoid confusion. My understanding is: 1. "dpkg architecture [name]" in that FAQ and "<Debian triplet>" in triplettable refer to the same identifier 2. "Multiarch Architecture Specifiers (Tuples)" in https://wiki.debian.org/Multiarch/Tuples is a distinct identifier from 1. Is that also you understanding? -- Alex Willmer <[email protected]> http://twitter.com/moreati
