On Wed, Mar 21, 2018 at 07:00:36PM +0000, Josh Branning wrote: > In regards to the patch ... > > 1) Why is this: > > if [[ $CARCH != $(uname -m) ]]; then > > 2) Any better than this: > > if ! setarch $setarch /bin/true 2>/dev/null; then
Those two checks are for different things. The first one checks whether the target CARCH is different from the host arch, and the second one checks whether we need a binfmt interpreter to run binaries for that architecture. These checks differ notably for i686 on x86_64. The CARCHs differ, but the setarch check succeeds, so no cross-arch binfmt magic is needed. > > The first doesn't change the cachedir if the host architecture is the same > as the build architecture. > > 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 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). > > 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. not quite following here, to be honest. > > 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. For the first, packages will not be mixed if the CARCH is different > from the host. 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). again, different checks, at different places in the script, for different reasons. the first check is for avoiding mixing of -any packages of different CHOSTs, and the second one is to try and figure out whether we need a binfmt interpreter. Best, Andreas -- ------------------------------------------------------------------------------ Andreas Grapentin, M.Sc. Research Assistant @ Hasso-Plattner-Institut Operating Systems and Middleware Group www.dcl.hpi.uni-potsdam.de Phone: +49 (0) 331 55 09-238 Fax: +49 (0) 331 55 09-229 my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------
signature.asc
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
