[continued from previous message]

Probably better Architecture-Isa, otherwise the current automatic<br>
case folding would make it end up as Architectureisa.<br></blockquote><div><br></div><div>Heh OK.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;  * dpkg-architecture emits DEB_HOST_ARCH_ISA and grows --host-arch-isa flag<br>

Also DEB_BUILD_ARCH_ISA and DEB_TARGET_ARCH_ISA, and also grows a<br> --target-arch-isa (but I&#39;m thinking whether the shorter --host-isa would<br>
be nicer, for example the --match-bits are not spelled --match-arch-bits,<br> which would seem also a bit redundant).<br>

&gt;  * dpkg-buildpackage passes --host-arch-isa to dpkg-architecture<br>

Yes, but only when not the baseline.<br></blockquote><div><br></div><div>I think what I meant here was that if you pass one of the --*-arch-isa flags dpkg-buildpackage, it gets passed along to dpkg-architecture (as --host-arch etc are).</div><div><br></

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

&gt;  * dpkg-genchanges should record the ISA in the changes file somehow I<br>
&gt; guess?<br>

Yes, also dpkg-genbuildinfo.</blockquote><div><br></div><div>Oh yeah. Although on a quick look dpkg-genbuildinfo gets the architecture from the filename...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex"> This could be done either from the<br>
envvars, or perhaps through the debian/files attributes support. But<br>
given that this is supposedly build global (I think it would be rather<br> weird to end up with a .changes including say _amd64.deb and<br>
_amd64v3.deb file references from the same build),</blockquote><div><br></div><div>Ah yes that&#39;s true.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> then
probably using<br>
the envvar might be the better way.<br>

&gt;  * dpkg-deb records the ISA in the file name<br>

Yes.<br>

&gt; Have I missed anything?<br>

Nothing else comes to mind right now (except what I might have already<br> added).<br></blockquote><div><br></div><div>Well of course I wrote this question in before going back and adding the stuff about having this all be driven by dpkg --add-archiitecture isa amd64v3 or anything like that. So those changes probably need to be
hashed out too?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; (Hmm does anything need to reject unknown values<br>
&gt; found in DEB_HOST_ARCH_ISA /  --host-arch-isa? Probably...)<br>

I guess it indeed makes sense to define what ISAs are supported, and<br>
either error out or warn and ignore such values. So there might be a<br>
need to add something like a new data/isatable.<br></blockquote><div><br></div><div>I notice that --add-architecture doesn&#39;t seem to do any checking.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">
&gt; Conceptually slightly separately, it might make sense to add a build<br> &gt; &quot;feature&quot; to Dpkg::Vendor::Debian to allow setting -march (and -mtune?)<br>
&gt; <br>
&gt; Then when we want to add support to an ISA, we add a little thing to<br> &gt; set_build_features (in either Vendor::Debian or Vendor::Ubuntu or wherever)<br>
&gt; that maps get_host_arch_isa() to values for the march-influencing feature.<br>

Hmm, right, how to hook this. I&#39;m not sure the current interface is good<br>
enough to describe this via build flags features, because such new feature<br> area would expose arch-specific features. I have been thinking through<br>
the build flags and will try to send a proposal/RFC to revamp parts of<br>
it during the weekend. </blockquote><div><br></div><div>Did that happen? I didn&#39;t see if if so.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But I think the
ISA stuff is better just handled<br>
(at leas for now) directly by injecting whatever flags when the requested<br> ISA is different to the baseline.<br></blockquote><div><br></div><div>Well that&#39;s easy enough too.</div><div><br></div><div>Cheers &amp; thanks for the continued thoughts,</div><div>mwh</div><div> </div></div></div>

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

[continued from previous message]

better, to avoid the implicit repetition of<br> ArchitectureInstructionSetArchitecture :), but that makes it less easy<br>
to associate both as related.<br>

In the end though, I think there are perhaps bigger constraints from<br>
the infra side of things than the package tooling, stuff like archive<br> management software, or binary transition migration and similar.<br></blockquote><div><br></div><div>I think I managed to convince myself that most things like britney and ben can and should treat each variant/ISA as a separate architecture. It depends a
bit how publication is done in the case where not all packages are built for all ISAs but not in very interesting ways I think. And my intention is to start with amd64v3 and build everything for this ISA (as we have heaps of builder capacity on amd64 in
Ubuntu) and sidestep worrying about that for a little while.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; In terms of building consensus around this design, I thought it makes sense<br>
&gt; to start at the bottom of the stack and so here I am on this mailing list<br>
&gt; :-) I guess in due course this could become a DEP, and would certainly need<br>
&gt; to be discussed on debian-devel before getting too far.<br>

I&#39;m not sure there&#39;s ever been much of a wide interest in something<br> like this in Debian TBH. Due to deployment and increased infra<br>
overhead at least?<br></blockquote><div><br></div><div>Yes that&#39;s fair. And as I said somewhere, I myself am not proposing to support any additional ISAs in Debian at this time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; What do you think? Have I missed any glaring implications?<br>

No, I think the overall picture is about right, and captures most of the<br> things we have discussed at various times and places in the past. :)<br></blockquote><div><br></div><div>I am very happy to read this!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)
;padding-left:1ex">
&gt; Is there a better way of doing this?<br>

I think starting from 5, the rest are probably just details to hammer<br>
out, but not insurmountable things.<br></blockquote><div><br></div><div>Great. The things I see as a bit vague at a base level currently are:</div><div><br></div><div>* Should the ISA influence the toolchain via toolchain defaults or dpkg-buildflags?</

<div>* How is the default ISA for a buildd chroot selected?</div><div><br></div><div>There is also the question of whether partial coverage of an ISA is handled by the package publisher or client side in apt but that&#39;s at least one level higher.</
<div><br></div><div>Cheers,</div><div>mwh </div></div></div>

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)