Faster emerge on the Raspberry Pi, Part III

Yesterday I posted a very hacky version of bsmerge, but didn’t elaborate enough on the problems associated with using it in its current state. So here are a few points that must be considered:

  • Packages depending on kernel sources should be emerged with care. The script currently pushes the local kernel config to the slave and tricks it into thinking it is the config of the kernel that’s running on the remote machine, but this is – like the whole script itself – a dirty hack.
  • Differing versions of sys-libs/glibc (and most likely many other essential system packages or normal libraries) are very likely to get you into trouble.
  • Currently, the binslave will install the packages with ROOT=/, which could easily render the binslave’s environment unusable.
  • Using the script might very well save your Pi’s SD card from a few read-write cycles, but it makes your phone’s suffer instead, and connecting that USB HDD to your phone instead of your Pi might prove to be a problem. I’m not exactly sure if this really is an issue with modern SD cards, but I can imagine that they are not too happy about the plethora of files that portage uses during its operation.

This list is by no means complete, and I’m sure that many other problems will crop up over time, but the message should be quite clear: ideally, the binslave chroot is an exact clone of your Raspberry Pi.

I’ll try to adapt the script to make it less crippled, but I can’t promise anything. In the meantime, use it with the utmost care –  or not at all 😉

Advertisements
Tagged , , ,

One thought on “Faster emerge on the Raspberry Pi, Part III

Comments are closed.

%d bloggers like this: