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.
_______________________________________________
Dev mailing list
[email protected]
https://lists.parabola.nu/mailman/listinfo/dev
