Woah woah woah hold on... So Poudriere doesn't automatically know package X relies on package Y and will build it first? It has to... I would expect way more errors than I'm getting and that would horrible design. I still prefer Portage over Poudriere at this time however I am forcing myself to live outside of Linux and really try to stick with it I don't like many of the design choices the kernel is headed and I dislike GNU as well as systemd reliance even on an init system like s6 or runit I needed specific packages to make other packages that rely on systemd happy so yeah I don't have it but I have to use workarounds anyways just to avoid it... in other words horrible design.
I think you got it wrong about Poudriere - Poudriere does not resolve dependencies. It runs those same
make
commands that you do in /usr/ports. The
make
command, run within the ports system, is what actually resolves dependencies. What Poudriere does is
set up a jail and some directories, but after that, it's simply scripting those same
make
commands in sequence. This is why I suggested that you first get comfortable in the ports system, and get used to the outputs. Once you know enough to start making a
repeatable list of chores that it takes to get to having your packages properly compiled, that's when you know you're ready for Poudriere. It's all about automation of those chores.
FWIW, Gentoo's Portage was inspired by FreeBSD's ports. And being able to troubleshoot your way out of self-created dependency hell serves you equally well on both the original (FreeBSD) and derivative (Gentoo).
IDK if Portage also has to act as a package manager and enforce/resolve dependencies. Poudriere just leaves those chores to
pkg(8) and
make(1), respectively.
Oh, and if you read the poudriere manpage, you'll discover that Poudriere doesn't care what options the ports have. If
make
is happy, that's all Poudriere needs... in fact, you can have several sets of those options, if you like.