[continued from previous message]
to src:dpkg to support variant ISAs as a thing:
* add get_host_arch_isa() to Dpkg::Arch
* dpkg-gencontrol records DEB_HOST_ARCH_ISA into DEBIAN/control as ArchitectureIsa
* dpkg-architecture emits DEB_HOST_ARCH_ISA and grows --host-arch-isa flag
* dpkg-buildpackage passes --host-arch-isa to dpkg-architecture
* dpkg-genchanges should record the ISA in the changes file somehow I
guess?
* dpkg-deb records the ISA in the file name
Have I missed anything? (Hmm does anything need to reject unknown values
found in DEB_HOST_ARCH_ISA / --host-arch-isa? Probably...)
Conceptually slightly separately, it might make sense to add a build
"feature" to Dpkg::Vendor::Debian to allow setting -march (and -mtune?)
Then when we want to add support to an ISA, we add a little thing to set_build_features (in either Vendor::Debian or Vendor::Ubuntu or wherever) that maps get_host_arch_isa() to values for the march-influencing feature.
Cheers,
mwh
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 31 Oct 2023 at 09:21, Guillem Jover <<a href="mailto:
guillem@debian.org" target="_blank">
guillem@debian.org</a>> wrote:<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
On Thu, 2023-09-21 at 14:43:42 +1200, Michael Hudson-Doyle wrote:<br>
> Thanks for the considered response. And sorry for the very slow reply.<br>
Idem! :)<br>
> On Wed, 6 Sept 2023 at 21:27, Guillem Jover wrote:<br>
> > I'm not sure I entirely agree with the requirements you set forth<br>
> > though:<br>
> ><br>
> > - I think such optimized builds might need to be done with "special<br>
> > toolchains" (these could simply be wrappers over the host compiler<br>
> > passing the appropriate flags via command-line or via specs or<br>
> > similar, not necessarily full blown toolchains), passing these via<br>
> > something like dpkg-buildflags seems currently unreliable, as I don't<br>
> > think we have full coverage in packages (neither for all compilers<br>
> > available)? Although it would be better as it would centralize the<br>
> > management. (For reference this is in part how rpm handles this:<br>
> > <a href="
https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in" rel="noreferrer" target="_blank">
https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in</a>)<br>
> ><br>
> <br>
> I agree that is not completely clear what the best approach here is, do we<br>
> change the defaults of gcc or influence things via default buildflags.<br> > <br>
> I'm sure there are packages that do not respect dpkg-buildflags during<br>
> build but the consequences of this do not seem all that great -- such<br> > packages would not be optimized for the variant / ISA but if someone<br> > manages to notice this, they can fix the bug.<br>
> <br>
> OTOH, having the compiler default change may be a bit of a surprise for<br>
> people who build binaries for deployment not via Debian packages. (Do our<br>
> compilers in general target the same baseline as Debian does for a given<br>
> architecture?).<br>
Right, given that the failure mode would be just "no-optimized-builds",<br>
and should not end up with those packages being broken, at most just<br> redundant with the baseline ones, then I guess controlling it either<br>
way would seem fine, yes.<br></blockquote><div><br></div><div>Ack.</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">
(Also if the packages are reproducible, and end up being not optimized<br>
this might be detectable as producing identical artifacts as on the<br> baseline.)<br></blockquote><div><br></div><div>This is an interesting idea -- although of course some care would be required to avoid false positives from things that do not use the C/C++ toolchain at all. Anyway... </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">
> > - Perhaps that's a limitation from the archive software side, but<br>
> > requiring to place the binary packages in the same pool seems<br>
> > rather restrictive (it forces different filenames for example).<br>
> We are considering supporting multiple variant/ISAs in the primary Ubuntu<br>
> archive, so if we get that far then yes, we want to have all the binary<br>
> packages in the same pool. The first steps don't have to support this I<br>
> guess.<br>
Ok. Just a note that even if served from the primary archive, there<br>
could be multiple pools (like the multi-pool setup on debian-ports),<br>
as the entry point are the (In)Release files.</blockquote><div><br></div><div>Oh OK. I don't think Launchpad supports that (but an not sure).</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, yes, the other<br>
option would be to use the variant/ISA name as a "fake arch" just in<br>
the binary package name.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > - I guess it might be nice for the ISA to be passed down to the<br> > > dpkg tools, but I don't think this is strictly necessary? A<br>
> > frontend like apt could also decide based on metadata in say the<br>
> > Release file, although not having the actual installed package<br>
> > metadata on whether it was a different ISA build or not would make<br>
> > its job more inconvenient. In any case I don't have a big issue<br>
> > with recording this via dpkg-gencontrol or similar if necessary.<br>
> I agree, I don't think it's /strictly/ required that the target ISA is<br>
> recorded in the deb. But I think adding a field for it reduces scope for<br>
> confusion later.<br>
Yes, agreed.<br>
> > On the specific implementation details:<br>
> ><br>
> > - As covered in previous discussions, dpkg could (but I don't think<br>
> > it's necessary) check whether the .deb is runnable on the current<br>
> > hw, but that's tricky as chrootless installs need to be taken<br>
> > into account, etc. It should certainly not be part of dependency<br>
> > resolution.<br>
> I'm sorry, what is a chrootless install? But I think I agree here too:<br>
> tricky and just not really worth it.<br>
<a href="
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap" rel="noreferrer" target="_blank">
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap</a></blockquote><div><br></div><div>Ah right.</div><div><br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)