I've just decided to install poudriere. I used it many years ago during a time when the config for it or pkg or both were seemingly in a bit of flux. Back then, I had set it up and liked how it worked, but I had some troubles over time. All that I recall now, as its been quite a number of years, is that something relating to the configuration of something caused it to break, I fixed that config but it broke again. It could be that part of the trouble was my own mistakes. Whatever it was, I abandoned poudriere for other ports management tools which worked, or none at all. I believe I went back to portmaster or portupgrade for some time, until having issues with those as well. So for a while I also used the ports build mechanism directly which had always been rock solid and always should be rock solid, period.
For the last few years I have used synth or direct builds. Since there have been in this last year or so, a bit of inconsistency with either the ports system itself or flaws with the build which synth cannot parse, I have also made a number of personal scripts. These scripts help me to rebuild all ports which had been built with dependencies that I wish to remove, dependencies which may or may not have exposed configs. One can remove a dependency with pkg, and it lists all the ports dependent upon it, but there is no way to reconfigure or rebuild each of them in turn so that an undesirable dependency is eliminated-- especially one not exposed by its config or Makefile.
The same situation is involved when switching default versions of python for example. I realize that in the distant past (while using PC-BSD as an initial base os) I used a port origin change with portmaster or portupgrade, and I know pkg has something like this. The trouble being, I do not use the first two tools, and I suspect that pkg would affect which pkgs are installed, and may not do everything I desire. That is, even if I were to instruct any of those ports management tools at invocation that any certain thing would have a port origin change, it would not necessarily rebuild everything involved. I am not aware of a way to do it with synth alone, either, so went to my own scripts.
I am certainly not expert with #!/bin/sh scripting, and sometimes my errors or changes to tools I use within my scripts cause unintended catastrophic failures. Recently though a failure lead to getting my GUI functioning again, since the error caused all of libdrm and dependents to be removed. The script failed to capture the list of what might be removed before it did so, the removal part was intended of course. I had no idea that libdrm needed to be rebuilt after a kernel rebuild, as I had not needed to do so in the past, it is now in the list of things to rebuild when I ever do so. Much easier than trying to determine which of any number of things becomes broken, I simply force a reinstall of all candidates.
I had introduced this post with poudriere , which I have now installed, soon I will see what builds with it that fails with synth or which should always succeed with a direct build but does not. I am uncertain whether any cruft remains from the previous attempt to use poudriere, but whether it is present or not, I still have to look at proper configuration for my system. The manpage for poudriere mentions a sample self-documented config file /usr/local/etc/poudriere.conf.sample which would be a good beginning and is often what I use initially if such a file exists. All I need to do (as root since any ports installs, management, and certain directory permissions would require it) is: cp /usr/local/etc/poudriere.conf.sample /usr/local/etc/poudriere.conf
But also of course, I shall look at the copy for what I might need to adjust, enable, disable. It is good practice to keep the original and revise a copy, or make a backup before revising the original. Either way, re-obtaining a file is at least a hassle and at most (worst case) impossible, we cannot guarantee remembering all the details. I tend to refer to instructions for tasks I've done innumerable times like updating kernel & world, and though I sometimes recall some details, I know that "how to update the locate database" is near the end of its manpage, some bad habits I suppose but they remain. Another recommendation which can be very helpful, is if any config file has a method for including comments or non-operative text, to add a comment to explain to your future self why you made any certain adjustment, possibly add where the tip was discovered.
One of the first things I notice is that poudriere can take advantage of my ZFS filesystem, so I toggle the appropriate settings. It appears that one MUST adjust this config if adapting the sample file, because the download address for fetch needs to be defined, below is what you get to start.
# Suggested: https://download.FreeBSD.org FREEBSD_HOST=_PROTO_://_CHANGE_THIS_
I am okay with the suggestion for now, so I substitute that. Next, I uncomment the data location line and enable portlint with a change from 'no' to 'yes' because why not?
POUDRIERE_DATA=${BASEFS}/data
# Use portlint to check ports sanity
USE_PORTLINT=yes
For the most part I kept the defaults because they are a good starting point or meet my needs. I chose to enable some debug type capabilities and limited it to 4 of my 6 processors. I expect that this poudriere config will itself change over time, so this is why I am not providing it in whole nor commenting on every value. I may list the few items I modified, but for now I believe I could try using poudriere , or perhaps not. Proof the manpage might need a slight bit of update in that yes it is still technically a valid example but has been unsupported since July 31, 2012:
First you have to create a jail, which will hold all the building infrastructure needs.
poudriere jail -c -v 8.2-RELEASE -a amd64 -j 82amd64
I was about to use 12.1-RELEASE since that is closest to what I have installed on my system, it is actually 12-STABLE or should be-- I need to verify this, because not only do I see my gkrellm showing 12.2 but it says 12.2-PRERELEASE which seems odd if I actually have 12-STABLE installed now. Maybe I need to make some adjustment to my /usr/src so it will be the newer -STABLE? Because of these inconsistencies and to verify whether 12-STABLE is a thing for poudriere, I did a google search and found, https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-setup which gives me proof and a bit different syntax below. The porters-handbook page appears to have been last modified September 11, 2020, 10:26:43 AM CDT, while the manpage is from March 4, 2019
poudriere jail -c -j 11i386 -v stable/11 -a i386 -m svn+https
I will adjust to my needs, and also arrange it to more closely match the command the manpage gave for easier comparison. This creates a jail, using version STABLE-12, architecture amd64, jailname 12amd64, and mode svn over https.
poudriere jail -c -v stable/12 -a amd64 -j 12amd64 -m svn+https
The above seems to work, though I do not like that it sits there not providing more feedback than "Checking out the sources with svn+https..." and after a while that part finally ends while I am not watching, to transition into a full buildkernel and buildworld it seems. I suspect that had I used a RELEASE version, It would simply download and unpack. The next step is to create the ports tree for it:
poudriere ports -c
So, now I am nearly ready to test it or do a full-blown run of things I would update on my system. The manpage tells me to create a plain text file with one port origin per line. This would be sysutils/gkrellm2 for example, followed by audio/asunder on the next line, and the same for a series of port origins of things I want to build. Lucky me, due to various struggles with things becoming uninstalled for one reason or other, I already have a number of file lists with this same formatting, both my scripts and synth use these when I have need of them. In order to begin a bulk build, I reference the file list when I invoke poudriere , pkglist in my home directory is the list used, and the jail for the building is 12amd64:
poudriere bulk -f ~/pkglist -j 12amd64
I chose one of the various file lists, happened to be 'Bunch-of-games' and discovered that I will have to rebuild the kernel and world of the host. I realize there is probably another way to solve the issue, but it is about time to update anyhow. This will also guarantee that I have a most updated and proper /usr/src. The error below is unlikely to occur if a RELEASE version is used since those do not fundamentally change with any applied updates, and such updates are rare in comparison to -STABLE.
[00:00:01] Warning: !!! Jail is newer than host. (Jail: 1202500, Host: 1201523) !!! [00:00:01] Warning: This is not supported. [00:00:01] Warning: Host kernel must be same or newer than jail.
In the process of writing another blog post relating to updating kernel and world, I verified that although oddly gkrellm says '12.2-PRERELEASE' my source directory is correct, as the output below shows. However, even more oddly, gkrellm now shows '12.2-STABLE' after a recent update around the time of writing that blog post.
root@ichigo:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/12 Relative URL: ^/stable/12 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 365688 Node Kind: directory Schedule: normal Last Changed Author: kevans Last Changed Rev: 365682 Last Changed Date: 2020-09-12 20:44:31 -0500 (Sat, 12 Sep 2020)
And so back to that previous command which was interrupted due to the poudriere jail install being newer than my host system.
poudriere bulk -f ~/pkglist -j 12amd64
Didn't I mention that often there always seems to be yet one more error to correct? This is especially true in the process of doing something new, setting up a new tool or process. Here is another interruption, another error. I chose to use ccache and have used it with synth or with ordinary (direct) port builds too, but now a config for poudriere needs adjusting, or the ccache config, or the ccache install itself.
[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for 12amd64-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Using packages from previously failed build: /usr/local/poudriere/data/packages/12amd64-default/.building
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-default
/etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-default/ref/etc/resolv.conf
[00:00:01] Starting jail 12amd64-default
[00:00:02] Error: CCACHE_STATIC_PREFIX used but /usr/local/bin/ccache is not static.
[00:00:02] Cleaning up
12amd64-default: removed
12amd64-default-n: removed
[00:00:02] Unmounting file systems
According to the error above, I believe the issue is that /usr/local/bin/ccache is a symlink, but I will have to check this to be certain and then I need to look at whether the poudriere config is what needs adjusting in some way to relate to it differently.
My first thought was wrong, static meant built with integral libraries instead of shared libraries, so the fix is an adjustment to the poudriere config, or a reconfigure and rebuild of ccache. I want to use ccache, and I should have read the poudriere configuration file more closely because it describes my mistake perfectly. My ccache was not built statically, so I will need to rebuild it. Hopefully a statically build ccache will not cause trouble with any other use of it as with synth or direct port builds. We usually learn more from our mistakes, but without this blog post I might not remember from one time to the next. So the rebuild of ccache with the revised 'static' config option enabled went much faster than I would have ever expected.
Now one last time to repeat that same command to initiate the build of some games, the list renamed to pkglist. No errors, it gets past the last hiccup and begins the building of those ports in the list. It seems that pkg itself had updated since the last time I built any ports by any method recently, so it is the first thing poudriere builds.
[00:00:00] Creating the reference jail... done [00:00:01] Mounting system devices for 12amd64-default [00:00:01] Mounting ports/packages/distfiles [00:00:01] Using packages from previously failed build: /usr/local/poudriere/data/packages/12amd64-default/.building [00:00:01] Mounting ccache from: /var/cache/ccache [00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/12amd64-default /etc/resolv.conf -> /usr/local/poudriere/data/.m/12amd64-default/ref/etc/resolv.conf [00:00:01] Starting jail 12amd64-default [00:00:01] Copying host static ccache from /usr/local/bin/ccache [00:00:03] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-09-16_17h59m11s [00:00:03] Loading MOVED for /usr/local/poudriere/data/.m/12amd64-default/ref/usr/ports [00:00:04] Ports supports: FLAVORS SELECTED_OPTIONS [00:00:04] Gathering ports metadata [00:00:12] Calculating ports order and dependencies [00:00:13] pkg package missing, skipping sanity [00:00:13] Skipping incremental rebuild and repository sanity checks [00:00:13] Cleaning the build queue [00:00:13] Sanity checking build queue [00:00:14] Processing PRIORITY_BOOST [00:00:14] Balancing pool [00:00:14] Recording filesystem state for prepkg... done [00:00:15] Building 534 packages using 4 builders [00:00:15] Starting/Cloning builders [00:00:16] Hit CTRL+t at any time to see build progress and stats [00:00:16] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.15.4 [00:02:11] [01] [00:01:55] Finished ports-mgmt/pkg | pkg-1.15.4: Success
Once this finally finishes, the next thing to figure out is how I will use the ports that poudriere builds into pkgs on the host system for poudriere, or in other words, how I can build with poudriere and use the pkgs it creates on the same box where they are built. This could be sticky, I believe it is mostly how pkg repos are configured, and I believe I can simply add one more repo definition to those already present in the configuration file. My system seems mostly responsive during this build of 534 packages, the list I gave was not even forty games, but gkrellm shows all six processor cores at above 90% use and top so far says load average of about 13!
In all fairness, right now I have firefox running with multiple windows, probably a hundred tabs, and one has a flash game in a tab. I'd exit firefox to see but since things are responsive I'm not too concerned right now. So far, 122 ports built in about 30 minutes with my loaded firefox running. Since I am more curious, I will now quit firefox to see what the difference will be. There was no drastic change as I may have expected. The load average depending upon what was being built reached as high as 20, often hovering around 18, and gkrellm showed the processors at 90% much of the time. All this means that firefox was not itself causing the high load averages or processor use.
The build finished and the last lines are below which followed a huge paragraph listing all the ports successfully built.
[07:18:43] Failed ports: lang/rust:build [07:18:43] Skipped ports: games/veloren [12amd64-default] [2020-09-16_17h59m11s] [committing:] Queued: 534 Built: 532 Failed: 1 Skipped: 1 Ignored: 0 Tobuild: 0 Time: 07:18:40 [07:18:43] Logs: /usr/local/poudriere/data/logs/bulk/12amd64-default/2020-09-16_17h59m11s [07:18:43] Cleaning up 12amd64-default: removed 12amd64-default-n: removed [07:18:43] Unmounting file systems
I cannot say right now whether my /etc/make.conf which is normally used would have meant that every port would build, or that port configurations which stray from default (as is often my preference) would affect the build either. There is mention, I believe in the poudriere manpage about copying a directory or linking it into the poudriere jail which would cause those port configurations to be used. I also realized after initiating the poudriere build that I forgot to set it up to use my make.conf as well. This means that although all those ports built on my system, they all used defaults, and therefore any number of them would be incompatible with what I have installed now. So I will need to correct those missing items I described and then do another build of the same things or other things. The good part is that having been run once, some things will be in its cache or that of ccache and the successive runs should each be a little faster, especially when dependencies are satisfied without needing to be built or rebuilt. There are quite a number of ports I build which use a default configuration.
First lets see what needs to be done for the port configs and then for the make.conf. Once those are set properly, I will also need to investigate how the repo built by poudriere would be accessed so as to install those packages, and set that in the appropriate pkg configuration file.
The port configs that I already have been using, that have been set by having built them at least once can be copied, the manpage says this:
As a starter, you may want to copy an existing /var/db/ports/ to
/usr/local/etc/poudriere.d/options.
My customized make.conf can also be used by making a symbolic link because then all methods I might use for building will remain synchronized. It would probably be better that the ports configuration directory be made accessible to poudriere as a symbolic link as well, but maybe I should have a seperate vanilla poudriere jail which would use default configurations. The manpage mentions the make.conf as below:
Create optional make.conf
You can also specify a global make.conf which will be used for all the
jails. Any of the following are allowed and will all be used in the
order shown:
/usr/local/etc/poudriere.d/make.conf
There are additional filenames which poudriere will use but the above is the first one and the most simple which I believe is the global one. If I were to set one per jail I would use a slightly different name:
/usr/local/etc/poudriere.d/<jailname>-make.conf
Now that I know how to get the port configs and my custom make.conf into the poudriere build system, there remains one more thing to clarify. My minetest Makefile is modified, so do I modify the copy in the ports tree of the poudriere jail or use some other method? Since I cannot find anything in the manpage that directly and specifically covers this situation in any other manner, I will copy or symbolic link to the modified Makefile for minetest or for any other port which has a custom Makefile I create.
Now that all of the details are finally set properly for that same list of games to be rebuilt, I can initiate a repeat poudriere build, but after I update the ports tree since it has been a few days. The only remaining task is to configure the pkg repo. Below, the manpage does mention the location of the poudriere created pkgs, the jailname will be different of course.
[Find your packages]
Once the bulk build is over, you can meet your shiny new packages here:
/usr/local/poudriere/data/packages/81i386
with 81i386 as the name of the jail.
The manpage for pkg mentions to see pkg.conf(5), which means:
man 5 pkg.conf
which gives you its manpage and contains the applicable instruction below:
REPOSITORY CONFIGURATION
To use a repository you will need at least one repository configuration
file.
Repository configuration files are searched for in order of the
directories listed in the REPOS_DIR array, which defaults to /etc/pkg/
and /usr/local/etc/pkg/repos/.
Filenames are arbitrary, but should end in ‘.conf’ For example
/usr/local/etc/pkg/repos/myrepo.conf.
There is also mention of an example file /usr/local/etc/pkg/repos/example.conf and details for how the repo.conf file should be constructed using ucl format, as well as a repo.conf example in the manpage text itself. Personally, I have more trouble adapting a rather specific example to my own needs than I do with adapting a generalized example or picking and choosing options in a very well commented configuration file. I often have a weird corner case as my need which is different than much of the documentation examples or I expect to do something which is not illustrated.
So my next step is to get the make.conf file set:
ln -s /etc/make.conf /usr/local/etc/poudriere.d/12amd64-make.conf
Lets try to use a symbolic link for the ports config below, I believe this should work but the manpage was slightly unclear whether I should copy the contents or the directory into the poudriere location. I will simply link the two, which would be more like copying the contents. The options directory does not yet exist, even after the previous ports build so i can be rather certain they were all built with defaults.
ln -s /var/db/ports /usr/local/etc/poudriere.d/options
I am usually confused about the order of the two when I create a symbolic link, I happened to be right for the first one and used the same order for the second one. If I do a long list for each of those two symbolic links, this is what I see which is correct:
# ls -l /usr/local/etc/poudriere.d/12amd64-make.conf lrwxr-xr-x 1 root wheel 14 Sep 19 14:26 /usr/local/etc/poudriere.d/12amd64-make.conf -> /etc/make.conf # ls -l /usr/local/etc/poudriere.d/options lrwxr-xr-x 1 root wheel 13 Sep 19 14:45 /usr/local/etc/poudriere.d/options -> /var/db/ports
Since using the packages which poudriere builds involves the last step and would be pointless if the most recent changes fail, I am going to test those two symbolic links by having poudriere build that same list of games, the command was:
poudriere bulk -f ~/pkglist -j 12amd64
The two symbolic links work. I am pleased that poudriere can handle an include at the end of one file to extend the make.conf with a second file, however, poudriere halts and gives the error message below:
make: "/etc/make.conf" line 67: Cannot open /usr/local/etc/synth/LiveSystem-make.conf make: Fatal errors encountered -- cannot continue make: Unknown modifier ':' make: Unknown modifier ':' make: "/etc/make.conf" line 67: Cannot open /usr/local/etc/synth/LiveSystem-make.conf make: Fatal errors encountered -- cannot continue eval: make:: not found export: make:: bad variable name
After a little investigation I discover that where poudriere will balk, the error is otherwise ignored as far as I know, or it might silently fail and the lines that follow it are then ignored. What it was, is a non-existent port which is referenced in my make.conf and due to no longer being present, the variable is invalid which poudriere doesn't like and halts. This should be true regardless, but possibly another variable construction would silently fail as it should because in this section of my make.conf I am only offering potential areas which may require kerberos which is an issue for some builds. Until I can figure out the new variable construction, I will leave things as they are and remove the lines which cause the failure. The line given as the error is after the actual error which is interesting and can lead to frustration, so either look to the line prior to the error or doublecheck any such variables which rely upon existence of a directory in the ports tree. The lines I removed from the/usr/local/etc/synth/LiveSystem-make.conf file are below, I highlighted the part which is the variable construction.
.if ${.CURDIR:M*/ports/devel/electron8}
OPTIONS_UNSET+=KERBEROS
.endif
I'll try once more and see if poudriere will build. Did I ever mention that I am rather gifted at discovering unexplainable errors? So, the error above is something which did trip up poudriere, BUT, and this is the weird part: if I combine the two files which comprise my make.conf, the error which poudriere tells me still remains on the same line number will no longer be an error and the build will start just fine. It looks like I will need to look closely at the two files, one which is rather tiny has an include for the second file which adds the bulk of my adjustments, and figure out what to do about having them both and whether synth needs them that way, or any other building needs them split. Until I decide, and in order to finally succeed with poudriere, I am going to combine the files into one large make.conf, and be done with it for now.
Once more I have forgotten about the modified minetest Makefile, so the build poudriere is working on now will not be all that I would wish it to create. It will be good enough for proof of build and for accessing as a pkg repo. When it finally finishes after less than seven hours I expect, I can look at the pkg repo access part, those docs for it I really do not like. I saw a BastilleBSD arrangement which would have poudriere building ports for a bastille jail, so maybe I can look at any repo configuration it has, except of course the rule of google says that any half-remembered data can not easily be re-found.
It built about 3 hours faster the second time but a number of things failed also. I believe a good chunk of those items which did not build were due to my own port configuration choices. Yes I am avoiding the pkg repo step. Since I set poudriere to use the same ports options database as the ports tree outside of poudriere , I was able to adjust a couple ports which i saw failed to build. Now I will try to get more successful builds in four hours or less but first lets update the poudriere ports tree:
poudriere ports -u
[00:00:00] Updating portstree "default" with portsnap...Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found. Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Fri Sep 11 14:55:09 CDT 2020 to Sat Sep 19 20:36:39 CDT 2020. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Fetching 839 patches. (839/839) 100.00% done.
Perhaps I should have updated the ports tree before the first attempt? We are nearing another FreeBSD release but 839 patches to the ports tree seems like a rather large number to have all at once. After some port config tweaks which I can do from outside of poudriere (because of the symlink to the ports config directory) all but one of the games successfully builds.
The last step, getting access to the built packages repo. The answer seems to have always been present. In /usr/local/etc/pkg/repos is a file for the synth repo which describes itself as automatically generated, and has all the information I need to create a repo file for the poudriere packages. What it began as is below:
# Automatically generated.
Synth: {
url : file:///var/synth/live_packages,
priority : 0,
enabled : yes,
}
What I modified it to be for the new file called my_poudriere_repo.conf looks like this:
# Set for test 9-20-20 8:20pm
poudriere: {
url : file:///usr/local/poudriere/data/packages/12amd64,
priority : 0,
enabled : yes,
}
I believe that when something is found by pkg for install it will place the name (highlighted) into square brackets. This means that those names could be anything descriptive or useful but I would limit them to one word to be safe, spaces might need to be handled a special way but its easier to just keep the name simple. The priority can be adjusted to make the new repo more important if I increase that value in the synth repo file. It seems like most things are working but when I test the new pkg repo, it gives me an error:
root@ichigo:~ # pkg install minetest Updating Synth repository catalogue... Synth repository is up to date. Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating poudriere repository catalogue... pkg: file:///usr/local/poudriere/data/packages/12amd64/meta.txz: No such file or directory repository poudriere has no meta file, using default settings pkg: file:///usr/local/poudriere/data/packages/12amd64/packagesite.txz: No such file or directory Unable to update repository poudriere Error updating repositories!
I believe this was a sticking point when I used poudriere years ago. I will have to look into how those files can be generated after any update to the built packages. I would have hoped it might be automatic. I looked in the poudriere.conf file and did not see anything right away. I didn't notice that there was a slight error with the pkg repo path, which means the manpage for poudriere needs another adjustment for accuracy, so in order for it to work, I need to modify that repo file slightly to look like this:
poudriere: {
url : file:///usr/local/poudriere/data/packages/12amd64
priority : 0,
enabled : yes,
}
I discovered the error because I was attempting the command below which I believe is what will finally initialize the repo as an accessible pkg repo on the system. This might also automatically occur if the file above had been correct when I tried to install a pkg. I am not sure whether this is now final and I will not need to repeat the command below, or if I should execute it periodically. If I am right that pkg will self-update each repo when attempting to install a pkg, then I am done.
pkg repo /usr/local/poudriere/data/packages/12amd64-default
So now I will again attempt to install minetest and see what it does.
The following 3 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
libgee: 0.20.1 [poudriere]
openblas: 0.3.10,1 [FreeBSD]
Installed packages to be REINSTALLED:
minetest-5.3.0 [Synth] (direct dependency changed: jsoncpp)
Number of packages to be installed: 2
Number of packages to be reinstalled: 1
The process will require 87 MiB more space.
7 MiB to be downloaded.
Proceed with this action? [y/N]:
This is very interesting. Three different pkg repos will be or could be used to satisfy the install. I know that the FreeBSD repo is remote and uses all defaults, the synth and poudriere repos are local and both use my port configurations (not default) or modifications. This also indicates to me that I may want to look at jsoncpp a little more closely.
Now I have multiple options to obtain a pkg to install as well as multiple methods for building them. I do not have any definite plans on which method I will use most but I'm sure that eventually I may favor one over the others, possibly poudriere, and I still need to copy that minetest Makefile into the poudriere jail, and I should not forget to hide the patch file as well (all this mentioned in Minetest better). The applicable directory is /usr/local/poudriere/ports/default/games/minetest but note default in the path, which I believe means I could possibly have a modified ports tree or other custom poudriere, and likely ties to the above mentioned repo config.
One other thing I have discovered while writing this blog post over the last week or so, is that it helped me be a bit more meticulous and detail oriented from start to finish because I wanted to provide all that information for anyone who may read this. Writing about it nearly step by step meant that I could keep track of my progress and know where I left off when I had to put the project on hold. I may have eventually succeeded but this process helped me work in a less random "scattershot" way. I think I should write a blog post about any new things I attempt as it will be useful to us both.
No comments:
Post a Comment
Thank you for your interest!