Hi Guillem,

Quoting Guillem Jover (2022-10-10 12:23:58)
> On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> considers its own arch the native one, and when operating on a cross-arch
> chroot, that goes wrong, both in dependency resolution and when outputting
> arch-qualified package names for example.
> 
> Fixing this properly is tricky though, because there are multiple
> requirements in tension here:
> 
>   * The external dpkg should be able to tell what's the arch for the
>     internal one w/o having to execute anything (that it might not be
>     able to run anyway).
>   * Setting a file on the database means either requiring a dpkg
>     maintscript (for the bootstrap phase) which we are trying to get
>     rid of, or offloading this to the bootstrappers (even worse), it
>     also means it could be modified w/o dpkg noticing, which can break
>     dependency resolution from an existing system.
>   * Shipping a file with the arch would seem like the best option (as
>     that is checksummed) and not in the db, but that means then, that
>     pathname under /usr needs to be selectable too at run-time, as
>     that encodes configure-time vendor-specific fsys layout.
>   * Setting that directory from the config file is currently
>     problematic as dpkg does not have a way to specify a different
>     config directory.
>   * Perhaps just adding a new --foodir option to dpkg could be enough
>     for now, if the inner dpkg uses a different pathname, in the
>     same way if it uses a different database pathname.
>   * But then only specifying the db pathname would no longer be
>     enough, and dependency resolution and arch-qualifying would still
>     be wrong. :/
>   * But then if the file does not exist (or cannot be found in the
>     «right» place) it could still fallback to the currently running
>     native arch, but that looks flaky (not worse than now, though,
>     but not ideal). :/
> 
> I guess I can prototype something with the --foodir idea though, but that's
> still rather meh.

once you have a prototype (even if it's not release-ready) feel free to share
it, because our CI setup is able to apply patches to source packages. So if you
have something that we can test, just send it over and we'll build a patched
dpkg to run this with our scripts.

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature

Reply via email to