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

[Josh Branning]

On 21/03/18 21:14, Luke Shumaker wrote:
> 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.

The current state (without the patch) is to keep package caches separate 
when using librechroot.

The patch makes it so they are not separate when the host is the same as 
the build.

>
>> 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.

Yes, I shouldn't have said cross-compile, rather I should have said 
"compile in a chroot". Even so, there is a possibility that you would 
want to compile the same architecture in a chroot with qemu, for 
instance, because of reproducible builds.

>
>>                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.

But they will be mixed when CARCH is the same as the host.

>
>> 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.
>

That is not what the code does in it's present state.

Try the following in a terminal:

if ! setarch i686 /bin/true; then echo "do the business"; fi

(change i686 to your architecture, or the architecture of the chroot)

May I further suggest you remove the exclamation mark from that line.

>>                              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.

I tend to agree this is perhaps the correct thing to do, but the code 
accomplish that in it's present state.

>
> 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.

I don't know what you'd be gaining by not keeping them separate.