On Wed, 21 Mar 2018 17:36:52 -0400, Josh Branning wrote: > The current state (without the patch) is to keep package caches > separate when using librechroot.
No, the current state (without the patch) is for librechroot to keep the package caches separate if building ARM-on-x86 or x86-on-ARM, but to share them if building x86-on-x86 or ARM-on-ARM. > The patch makes it so they are not separate when the host is the same > as the build. It does that with or without the patch, that behavior isn't being changed. Of Parabola's supported architectures, i686-on-x86_64 is the only case that this patch changes. > >> 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; ... > > 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. librechroot/libremakepkg always build in a chroot. db-update on the server rejects packages that aren't built in a chroot. We _always_ build in a chroot. Even when building for the host architecture. (In fact, it's relatively recent that libremakepkg--which has always built packages in a chroot--gained the ability to compile packages for architectures other than the host architecture.) > >> 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. Right. The goal of the patch is to split the cache between architectures. An x86_64 host and all x86_64 chroots can share the same cache with eachother, but not with armv7h chroots or i686 chroots. > >> 2) Any better than this: > >>> if ! setarch $setarch /bin/true 2>/dev/null; then > >> > >> 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. Yes it is. > 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) In this example, `echo "do the business"` is the code that only needs to run if we will be using an interpreter. My x86_64 kernel can run x86_64 and i686 binaries without an interpreter, so that snippet keeps quiet when I type "x86_64" or "i686". But it does need an interpreter to run armv7l binaries, so it prints the message when I type "armv7l". > May I further suggest you remove the exclamation mark from that line. No, because that would be wrong. > > 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. Yes, it does. > > 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. Disk space, download time; you know, the reasons you use a cache at all. The reason to keep them separate is that the way db-import-alarm-pkg used to work meant that sharing a cache between architectures would result in package signature errors for arch=(any) packages. It was a hack to work around something that db-import-alarm-pkg did wrong. Now that we have a correct unified db-import-pkg, I no longer think that we should have the package cache hack at all. -- Happy hacking, ~ Luke Shumaker _______________________________________________ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev