Hi! On Fri, 2016-02-12 at 10:40:53 +0000, Alex Willmer wrote: > On 11 February 2016 at 18:22, Guillem Jover <guil...@debian.org> 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?
If that's what config.guess returns then that's fine from the GNU config point view, but for dpkg we just ignore the vendor field. GNU config knows when to add the vendor field if it's missing, for example: $ /usr/share/misc/config.guess x86_64-pc-linux-gnu $ usr/share/misc/config.sub x86_64-linux-gnu x86_64-pc-linux-gnu For CloudABI, doing some checking: $ /usr/share/misc/config.sub x86_64-cloudabi x86_64-pc-cloudabi and reading the code, it confirms that «-cloudabi*» by itself is the os/abi component, so «unknown» here is definitely the vendor. > >> --- 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. Ah nice! > > 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[^-]* Right. > and the triplettable addition > > # <Debian triplet> <Debian arch> > # cloudabi-none-<cpu> cloudabi-<cpu> > > since cloudabi is "kernel independent". Well, given that cloudabi is not a kernel, I'd use a Debian arch name with a three elements-form, so that it does not get confused with a kernel. Similar to the musl or uclibc arches, but with none for kernel. Say «cloudabi-none-<cpu> cloudabi-none-<cpu>». > Finally, to avoid confusion. My understanding is: > 1. "dpkg architecture [name]" in that FAQ and "<Debian triplet>" in > triplettable refer to the same identifier Not quite. The architecture name is the external representation, used by most things in Debian: fields in debian/control, in .deb filenames, etc. The Debian triplet is the internal representation used by dpkg to have a unified representation so that it can do proper matching with wildcards, and to be able to convert from and to GNU triplets. > 2. "Multiarch Architecture Specifiers (Tuples)" in > https://wiki.debian.org/Multiarch/Tuples is a distinct identifier from > 1. The multiarch architecture tuples exist mostly to cope with the i386 odd case in Debian (fortunately or unfortunately depending how you look at it), which uses a different name depending on the base ISA we compile for. But you don't need to worry about this, because dpkg-architecture will take care of this for you. Thanks, Guillem
