[Dev] [PATCH] libretools: fix i686 gpg signature failures

[Luke Shumaker]

To address the big picture: A better subject line might have been
"librechroot: don't share the package cache directory between
architectures".  I think both you and I agree that this patch
correctly achieves that objective.  The discussion so far has been
about whether that *objective* is correct, or if different
architectures should share a package cache.

----

To address the details:

First of all, the function being modified is hack_arch_nspawn_flags,
the entire function is a hack, and none of it is particularly elegant.
Just keep that in mind.

On Wed, 21 Mar 2018 15:00:36 -0400,
Josh Branning wrote:
> 
> In regards to the patch ...

(I'm going to re-order your paragraphs a bit, so I'm not jumping back
and forth between the two cases in my replies.)

> In regards to the responses on the mailing list regarding mixing
> packages/overrides etc. I'm not sure how they correspond to the code
> in the patch.

This patch keeps package caches for different architectures separate;
that discussion is about whether this is the right thing to do.

> 1) Why is this:
> > if [[ $CARCH != $(uname -m) ]]; then
> 
> The first doesn't change the cachedir if the host architecture is the
> same as the build architecture.
> 
> For the first, bare in mind there is a possibility that you would want
> to cross-compile to the same architecture for some reason
> (e.g. reproducible builds).

We (libretools) don't cross-compile the way some other projects
cross-compile; we never use a cross-toolchain, we always use the
target's native toolchain, and use user-mode processor emulation to
make that possible.  "Cross-compiling" to the host architecture isn't
possible, because that would mean telling the kernel to use qemu to
run native ELF files, which you can't do because qemu itself is a
native ELF file, and it would get stuck in a loop.

>               For the first, packages will not be mixed if the CARCH
> is different from the host.

Right, that's why it's what was used; that's what this patch is
accomplishing.

> 2) Any better than this:
> > if ! setarch $setarch /bin/true 2>/dev/null; then
> 
> The second is a bit complicated, but as I gather, sets the
> architecture and runs /bin/true. If /bin/true returns false (something
> to do with setting the architecture fails), then the code is run. I
> may have got this wrong, but frankly I would be surprised if this
> works as it should and I like surprises.
> 
> For the second, I guess you want to know if you are compiling in a
> chroot or not, which makes sense, but I'm not 100% convinced that code
> works correctly just from reading.

This will always be compiling in a chroot (this is code in
libreCHROOT, after all).  That isn't the question.  The question is
"is the architecture of the chroot one that the host kernel can run
natively, or one that requires an interpreter?"  `setarch $target`
will fail if the kernel can't run $target binaries natively.

>                             For the second, packages will not be mixed
> if a chroot exists (that is ... if the code works as it is presumably
> intended ... something I am not entirely convinced on at the moment,
> but soon may be).

Not quite, see above.  The reality is:

For the second, packages will not be mixed if we need an
interpreter to run target binaries.  That seems a little silly--the
interpreter has nothing to do with the package cache.  It's a
hack--right now, for Parabola's supported architectures (x86_64, i686,
and armv7l), that means it splits the caches between x86 and ARM,
which was the correct thing when I first wrote the code.

Andreas is saying that since the archlinux/archlinux32 split, it is no
longer correct to lump the package caches for i686 and x86_64
together.  I disagree, and am saying that since migrating to
db-import-pkg, it is no longer necessary to keep any of the package
caches separate.

-- 
Happy hacking,
~ Luke Shumaker

Pardon any typos, I'm still getting used to my new Model 01 keyboard.