[continued from previous message]
This can be used among other things to set up foreign chroots, by<br>
running the host tools, so disallowing installation could be<br>
problematic. Even though I guess there could be a warning about this,<br>
or maybe it could be controlled through a force option, although both<br>
seems like they could be disruptive.<br></blockquote><div><br></div><div>Of course in such cases dpkg knows that something funny is going on and could suppress the warning itself. </div><div><br></div><div>I spent a few minutes trying to think hard
about this and I honestly don't think I can predict whether trying to prevent installation of incompatible packages is worth it (after all one of the ways users could get into trouble would be moving an installed system to a different CPU and having
binaries start to fail and obviously dpkg can't help there).</div><div><br></div><div>One result of this thinking was: I had been thinking/assuming the issue of which variants to consider would be apt configuration, but maybe dpkg configuration would
make more sense (after all, --add-architecture is a parameter to dpkg). And in this case, dpkg could object when installing a variant that has not been configured.</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">
> > - I'm not fond of having to change the binary package name format<br>
> > either for this (name_version_arch.deb) even if at least dpkg<br>
> > itself does not care (but I know other tools do care), and<br> > > depending on the format I'd expect things to break (this goes<br>
> > back to the shared pool concern).<br>
> <br>
> I don't think this is avoidable in the long run. I must admit I have<br>
> generally thought of the presence of the architecture name in the .deb file<br>
> name to be more a convention than part of the format (and the "real"<br>
> indication of a binary package's architecture is in DEBIAN/control).<br>
Yes and no I guess. In theory the (canonical) information should be<br> extracted from the DEBIAN/control from inside the .deb, in practice<br>
I think tools (?) (might) try to use heuristics from just the filename<br>
to avoid having to open, uncompress and parse every .deb around, for<br> performance reasons.<br></blockquote><div><br></div><div>True. In fact it looks like apt-ftparchive does this (when using the --architecture flag at least) so I get to care about this a bit...</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">
If the only change in the package filename format is in the <arch> part<br>
where we'd use a name which would otherwise be valid as an arch name (so,<br>
no weird symbols, or «-» separators that are not intended to split <os><br>
and <cpu> or similar), then using a name for the variant/ISA would be<br> fine.<br></blockquote><div><br></div><div>Right. I think that (when possible pretending e.g. "amd64v3" is a distinct architecture will generally make things easier. E.g. I think britney wouldn't need to know about the relationship between &
quot;amd64" and "amd64v3". </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">
> > - If dpkg-architecture needs to be aware of this, then this might need<br>
> > to be auto-detectable from just the current toolchain being used.<br>
> So you are saying to configure a build environment for, say, x86-64-v3 you<br>
> would configure gcc with --with-arch64=x86-64-v3 and then dpkg-architecture<br>
> would parse the output of gcc -Q --help=target to set DEB_HOST_ARCH_VARIANT<br>
> appropriately? (modulo mistakes in details) Or do you mean something else<br>
> entirely?<br>
That would be one solution yes, which could give automatic bijective<br> mappings, although ideally with a machine-readable way to get at it,<br>
which I'm not sure we have currently. </blockquote><div><br></div><div>I think "gcc -Q --help=target | grep -e '^\s*-march'" is about as machine readable as it gets currently, for better or worse (mostly worse).</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">For example code in dpkg-dev<br>
already runs «$CC -dumpmachine» to infer the host architecture to use<br> during builds.<br>
While using a triplet variation could be a way to do that, that would<br> require such triplet support for each variant/ISA, which tends to be<br>
very painful to introduce if it's not there already, so I'd not<br> consider this specific way a viable option.<br></blockquote><div><br></div><div>I admit I'm not an expert on triplet intricacies but I think a new triplet is not appropriate here (a bit like a new Debian architecture for a variant/ISA choice is not
the right concept).</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">
> > Some of the above problems could perhaps be avoided if we introduced<br>
> > a concept of architecture aliases/ISAs (similar to what rpm has), which<br>
> > would side-step the pool sharing issue, the binary package renaming,<br>
> > etc. One big issue with this is that it requires for dpkg to have an<br>
> > exhaustive table of all such aliases, and if there's ever a new alias<br>
> > added, old dpkg versions need to be updated or they will not understand<br>
> > what they match with. So this does not seem ideal either. So I guess this<br>
> > is a variation over your proposal, but perhaps this could still be used<br>
> > in specific contexts, say only at build-time (but not for dependency<br>
> > relationships), for repo management (say binary-arm64v9/Packages.xz),<br>
> > or binary package names where the field would specify the actual name<br>
> > for the filename, say:<br>
> ><br>
> > Architecture: arm64<br>
> > ArchitectureIsa: arm64v9<br>
> ><br>
> > or maybe better:<br>
> ><br>
> > Architecture: arm64<br>
> > ArchitectureIsa: v9<br>
> ><br>
> > resulting in dpkg-deb generating:<br>
> ><br>
> > binpkg_1.0-1_arm64v9.deb<br>
> ><br>
> > but targeting arm64.<br>
> I'm not sure but I think you have talked yourself into suggesting something<br>
> very similar to my proposal here?<br>
Ah sorry, yeah, didn't mean to present it as a new idea, </blockquote><div><br></div><div>:-)</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">I was mostly<br>
trying to walk over the issues, and refine upon your initial idea,<br>
with those constraints applied. :)<br></blockquote><div><br></div><div>I'm certainly glad you got to a similar place as me!</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">
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)