Re: Architecture variants for Debian / Ubuntu

On Fri, Nov 03, 2023 at 02:02:37PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2023-11-02 at 15:27:54 +0000, Michael Hudson-Doyle wrote:
> > On Tue, 31 Oct 2023 at 09:21, Guillem Jover wrote:
> > > This can be used among other things to set up foreign chroots, by
> > > running the host tools, so disallowing installation could be
> > > problematic. Even though I guess there could be a warning about this,
> > > or maybe it could be controlled through a force option, although both
> > > seems like they could be disruptive.
> 
> > Of course in such cases dpkg knows that something funny is going on and
> > could suppress the warning itself.
> 
> Right, also true.
> 
> > 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).
> > 
> > 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.
> 
> Yes, the "plan" has been to add support for run-time CPU attributes,
> so that when adding a new arch, for example you can specify whether
> that arch is runnable, which could help dpkg decide whether to allow
> by default to install M-A:foreign packages.
> 
> I guess this is similar, so such future interface should probably take
> this into account as something to support too. Will check where this
> is tracked and add a note to it.
> 
> And of course that is fine as a guardrail, but if a user hit that out
> of running a frontend, then that would already be too late, which to
> me means that frontends need to be aware of this too (and not pass
> packages that dpkg would/could/might refuse to install), when deciding
> what to pass to dpkg.
> 
> But in any case, as you say, this currently would not be worse than
> configuring a foreign arch, installing some foreign package and trying
> to run it, but it might make it potentially more common. And as
> mentioned above the effecting layer this needs to be decided up seems
> higher anyway (even if dpkg could provide the infra for it).

So I'd like to interject here for a moment with my APT hat, because I
want to have ISA autodiscovery. I want to be able to configure the
system such that APT automatically picks the best ISA to download,
and not have to configure a specific one.

Similar to when you pass -cpu host to qemu, I want a magic alias
for dpkg ISA support to say "host" or whatever and APT can then go
and pick the best one (possibly multiple ones).

It's fine for dpkg to provide a list of all architectures and the
preference ordering in that case I think.