Hi!
On Fri, 2023-06-16 at 16:29:17 +0200, Johannes Schauer Marin Rodrigues wrote:
> 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.
I provided a prototype patch some time ago which got integrated in
Helmut's dpkg-root-demo CI system. But I've not been entirely happy
with it though. I've been rethinking about it from a clean slate and
I went with a file in the db instead which seems way cleaner after all.
My current reasoning is:
* Shipping a file under /usr/share means:
- The chroot has no defined native arch until dpkg is unpacked, which
again imposes an installation ordering, which we'd rather avoid I
think.
- It also requires to install a dpkg in the chroot! (Which is generally
desirable but might not be in cases such as for testing purposes.)
- It requires hardcoding a filesystem pathname (worse) in addition to
the database pathname.
- It creates a public interface.
* It creates a potential out-of-sync situation between the admindir
and the root directory, as these can be specified separately.
* It would require adding a new --foodir option for this new
directory.
* If we need to pre-create the file in the chroot, I think doing
that inside the db is always preferable than creating one in the
filesystem part, because the latter is a filesystem policy
governed by the chroot distributor, and is part of the packaged
data while the location of the latter is still a policy issue,
it is something already handled by the tooling and more
independent than the packaged bits.
* In the future pre-creating the file could be done by extending
dpkg to provide a new dpkg action to initialize a chroot db for
example, that could hide any such detail, while doing the same for
the chroot filesystem seems just wrong.
The annoying part is that this information is already present in the
Architecture field for the dpkg package, but that is also a downstream
policy decision and I'd consider it a regression to try to infer the
package name dpkg itself is being packaged as inside the chroot, not
to mention that still does not cover some of the points above anyway.
I've queued the changes and I'm planning to push them during the
weekend.
Thanks,
Guillem
