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. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
