So let me make the first post here (excluding OP of course haha).
So what you are seeing in the above screenshot is my new poudriere set up running in my FreeBSD 13.0-RELEASE server (Which is hosting xyinn.org and these forums). I normally use binary packages through \"pkg\" to upgrade and install packages on my server and only use ports a little bit for some specific things, however mixing ports/binary packages is not really recommended because there could be problems with the generic build configuration packages that are provided by the upstream build server (All binary packages provided by FreeBSD are built with the default flags and the default configurations) and the configuration options you may have set locally. For a while, this has affected me in that FreeBSD 13.0 uses postgres 13 as its default postgres implementation, however, I’m using postgres 14 on this server. This also means that there are particular binary packages that I installed (like let’s say php74-pgsql driver for php that links to postgres 13 since that’s the default in FreeBSD 13 and it’s a driver I need for this forum to operate). This means that I have had to:
1. Do some local tweaking to make postgres 14 the default.
2. I need to use ports to build the php psql driver (databases/php74-pgsql) that is linked to my local default postgres of version 14 (ports will install this as its own binary package as well so \"pkg\" will register and detect that correctly).
3. I need to watch out for updates that try to remove or downgrade my postgres implementation due to these differences between binary packages.
Now in this case, the problem is still there in that when I do another upgrade to the system, whenever it detects that the php74-pgsql package has changed by upstream, it will try to downgrade or just flat out fail the build because of these conflicts. The solution recommended by the FreeBSD community is to use poudriere to automatically build all of these ports packages for me, for my specific freebsd version, using my specific configuration, and it will automatically create binary packages in a directory structure that is the exact same as what \"pkg\" uses. Afterwards, I can simply point my host’s package server to target that poudriere location (hosted over http), and that’s it. The host won’t fight anymore with upstream, because upstream is actually my own build server that has the same exact build configuration that I wanted to have (same as upstream but with psql 14 as my target default postgres version).
A lot of this reminds me of stuff I used to do when I ran Gentoo and had to set up my own binary package server (PORTAGE_BINHOST), but the FreeBSD one is a lot better, simpler, stable, and I don’t have to do as much of the work that I used to do given that back when I was on Gentoo, I was actually pushing development for these types of features, primarily in relation to my ZFS work.
Also poudriere uses jails to isolate all of the build instances, I have it integrated with ZFS as well so it will automatically create datasets to put its files in. It can even cross compile! (amd64 <> i386 for instance). Poudriere is also what FreeBSD themselves use to build all of their packages from what I know. So that’s pretty cool.
Example: FreeBSD Package Status.
I also found
this PDF by the creator of poudriere, Bryan Drewery. I haven’t finished reading it yet but it’s pretty cool.
This is also an
example of having two separate build directories, fully isolated, from two separate FreeBSD branches on the same box. The first one in this case will be building packages for 13.0 RELEASE amd64, and the second is building for CURRENT (HEAD) on i386. I haven’t gotten into STABLE/CURRENT stuff yet, but I foresee I’ll need to do this soon if I want to switch my framework laptop from Linux Mint to FreeBSD, which I’ve been dying to do, and support is slowly coming along (It’s pretty much mostly running it seems but there are some kinks).
Code:
poudriere jail -c -j 130amd64 -v 13.0-RELEASE -a amd64
poudriere jail -c -j current -v head -a i386
All of these jails can either have shared \"make.conf\" configuration or can even have their own set of configs, or a combination of them. There is a defined hierarchy which you can take a look at
here, search for \"Create optional make.conf\".
- fearedbliss