Hi folks.
I just wanted to share some details about a setup of HaikuPorter / HaikuPorts that has been working great for me.
Originally, I kept a haikuports repo for 64 bits, and a different one for 32 bits… all on slow HDD. was a major PITA. Specially painfull at the moment of trying to reclaim disk space via by removing workdirs (eg, cleaning up Python 3.10 work dir, 20k+ files, would take over 6 minutes).
After finally been able to buy an SSD, it was time for even more improvements.
Now I have only one repo for both 32 and 64 bits, that I can use from beta5 or nightlies. The recipes, patchsets, downloaded tarballs, and the final .hpkg files remain on the SSD, but the “work-dirs” (where the tarballs get unpacked/patched/compiled) are in RAMFS.
Makes for a much nicer, and faster, setup, and “cleanup” is automatic upon reboot/shutdown 
(and no more having a bazillion port.recipe files liying around for ports I’ll never touch). As the “recipes” repo as far fewer files, using find/grep/query also become faster (difference is noticeable at least on my lowly Phenom II).
Another benefit of this setup is: reduced wear on the SSD. I’m dumb, make many mistakes while working on recipes, thus end up doing lots of repeated builds. Not sure if my “el cheapo” SSD could survive long that kind of abuse 
.
Granted, this setup has some caveats, such as
- you need to remember to extract .patchsets before rebooting (and if on a desktop, having an UPS would make me feel safer), or risk loosing modifications that you may have made under
$sourceDir. - need to remember that .recipes are in one place, and $sourceDir in another. Gets alleviated with practice (or by writing some custom small helper scripts).
- some rare port might failt to build on RAMFS, but work OK if built on SSD/HDD.
The latter has been getting less and less frequent for me, IIRC, last failure I had was with mozc (a fairly large package). Post-beta5 changes should make it even less frequent.
Anyway… to the details:
First, I make sure I have a /RAMDRIVE at startup.
My /boot/home/config/settings/boot/UserBootscript contains at the end:
mkdir /RAMDRIVE && mount -t ramfs /RAMDRIVE
# So I always get /RAMDRIVE in the same place:
copyattr /boot/home/config/settings/Tracker/RAMDRIVE_attribs /RAMDRIVE
And then I configure HaikuPorter like this:
# HaikuPorts configuration
# Expected location: ~/config/settings/haikuports.conf
# Required settings:
TREE_PATH="/Data/haikuports"
PACKAGER="your name here <foo@bar.com>"
# Optional settings:
ALLOW_UNTESTED="yes"
TARGET_ARCHITECTURE="x86_64"
# Custom locations to be able to use the same "haikuports" clone for both 32 and 64 bits x86.
DOWNLOAD_IN_PORT_DIRECTORY=True
# Add "mkdir /RAMDRIVE && mount -t ramfs /RAMDRIVE" to UserBootscript, for example.
OUTPUT_DIRECTORY=/RAMDRIVE
# Only one package dir for all archs:
PACKAGES_PATH=/Data/haikuports/.packages
# When using RAMFS for OUTPUT_DIRECTORY, we only need one separate repository per primary arch:
REPOSITORY_PATH=/Data/haikuports/.repository-x86_64
ALLOW_UNSAFE_SOURCES=True
I use a similar file on my 32 bits installs, with the only changes being:
TARGET_ARCHITECTURE="x86_gcc2"
SECONDARY_TARGET_ARCHITECTURES="x86"
REPOSITORY_PATH=/Data/haikuports/.repository-x86_32
/Data is a partition I can access from the different Haiku installs.
Why, oh, why, I didn’t used this setup earlier? Just because I didn’t even knew about some of those config variables 
Only became aware of them when attempting to hack in HaikuPorter’s source code, to be able to accomplish basically just this exact setup
Note: this setup works fine for me both on bare-metal, and on VirtualBox/VMware. (all my installs are on physical partitions, that I can boot both in bare-metal or from the VMs).
Originally, my VMs had assigned 2 GB of RAM, as that was enough for most of my Python-related recipes. Now using 4 GB, after working on updating numpy/scipy and other heavier stuff. Don’t be afraid to experiment to see what works best for you.
Hope some of you may find it useful. Happy HaikuPorting!
