Into a wall about face

Sometimes because of your own insistence at having the most current software and doing frequent updates, you slam head first into another's oversight.  This is not always a huge issue but it can be.  When you discover in the process of updating that you've found a dead end, you cannot go forward and immediately going backward is also impossible, you may need to do something a bit more drastic, but happily not a clean fresh install.

Recently, once again, something related to security/ssl broke many things, and as I was partly through updating I had also lost the previous install of security/libressl.  My first idea was to figure out what version of libressl I had before things went wrong, I knew part of the issue was the newer version being incompatible.  Due to that or some other combination, security/py-cryptography also could not build, and from there lang/rust was also affected.  Between py-cryptography, libressl, and rust, I was without any direct method to do much of anything on my box.  Firefox was broken, my irc clients wouldn't start, but luckily I had some things setup properly on my system although disabled or unused.

Trying to backtrack libressl by modifying the version number in its Makefile and removing distinfo and pkg-plist files worked, except that I discovered other ports which needed the same process to get these older versions built.  Although the second port I tried to change in this way wound up in failure, I also figured that I was going to discover yet more things I'd need to manually edit, so I gave up on this idea for the solution.  What I knew I could do is revert my ports from the most current to quarterly, and this I could do very easily with gitup.  I have been using a short script that eliminated some typing, so I just need to switch 'ports' to 'quarterly' in my script which calls gitup.  The configuration file for gitup already has this set as an option but as I mentioned, it was unused.

cat /usr/local/etc/gitup.conf

# $FreeBSD$
#
# Default configuration options for gitup.conf.
{
	"defaults" : {
		"host"           : "git.freebsd.org",
		"port"           : 443,
#		"proxy_host"     : "",
#		"proxy_port"     : 0,
#		"proxy_username" : "",
#		"proxy_password" : "",
#		"source_address" : "",
		"low_memory"     : false,
		"display_depth"  : 0,
		"verbosity"      : 1,
		"work_directory" : "/var/db/gitup",
	},

	"ports" : {
		"repository_path"  : "/ports.git",
		"branch"           : "main",
		"target_directory" : "/usr/ports",
		"ignores"          : [],
	},

	"quarterly" : {
		"repository_path"  : "/ports.git",
		"branch"           : "quarterly",
		"target_directory" : "/usr/ports",
		"ignores"          : [],
	},

	"release" : {
		"repository_path"  : "/src.git",
		"branch"           : "releng/13.1",
		"target_directory" : "/usr/src",
		"ignores"          : [
			"sys/[^\/]+/conf",
		],
	},

	"stable" : {
		"repository_path"  : "/src.git",
		"branch"           : "stable/13",
		"target_directory" : "/usr/src",
		"ignores"          : [
			"sys/[^\/]+/conf",
		],
	},

	"current" : {
		"repository_path"  : "/src.git",
		"branch"           : "main",
		"target_directory" : "/usr/src",
		"ignores"          : [
			"sys/[^\/]+/conf",
		],
	}
}

Somewhere in the process of this whole mess becoming an issue, gitup was no longer working either.  Thankfully I still had connectivity so all I needed to do is grab the FreeBSD pkg for it.  In order to do this, I have to re-enable the FreeBSD pkg repo which I generally avoid in lieu of my own poudriere built ports, local repo.  My configuration file has two similar sections, and enable section and a disable section, all I need to do is switch which lines are commented out.

cat /usr/local/etc/pkg/repos/FreeBSD.conf

# $FreeBSD$
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#
#
#FreeBSD: {
#  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
#  mirror_type: "srv",
#  signature_type: "fingerprints",
#  fingerprints: "/usr/share/keys/pkg",
#  enabled: yes
#  priority: 0
#}

FreeBSD: {
  enabled: no
}

My local poudriere repo configuration file I do not need to change at all, although it has a disable section as well.

cat /usr/local/etc/pkg/repos/my_poudriere_repo.conf

# Set for test 9-20-20 8:20pm
# revised for stable-13 2-13-21 2:48am

poudriere: {
  url      : file:///usr/local/poudriere/data/packages/13amd64-default,
  priority : 10,
  enabled  : yes
}

#poudriere: {
#  enabled  : no
#}

With this changed, I can do pkg install gitup, and having revised my script, I can tell gitup to revise my /usr/ports to quarterly.  After my ports are effectively reset to an earlier time, I can tell poudriere (since I have it configured to use that same ports tree as I would for manual builds) to re-build any number of lists of bulk port builds.  Simply issuing a pkg upgrade after the ports tree was reverted and while the FreeBSD pkg repo was enabled caused many things to be reinstalled, a few to be updated (was not expecting that) and a few things to be uninstalled.  When I set poudriere to do the first bulk build, I discovered that ccache installed from FreeBSD pkg repo was not a static build/lib which poudriere requires.  This is when I disabled the FreeBSD pkg repo in favor of exclusively using my own local repo from poudriere, and then I manually rebuilt and installed ccache with the correct options.

Part of the problem is my own, for being a bit excessive with trying to have the most current ports on my system.  This is possibly essential for my unofficial port tree leaf git repos for those ports I maintain on my own.  The rest of the cause for my recent troubles is from ports maintainers not recognizing a breaking change.  I did check /usr/ports/UPDATING after this struck me, and it simply mentions the libressl upgrade but not that some other thing is not yet compatible with the newest 3.5.3 version.  I would strongly suggest some sort of way to be more certain that all ssl changes are compatible before openssl or libressl are updated as a final commit to the ports tree.  We can find a way out of our predicament but it wouldn't hurt to not have an unknowing pitfall exposed if it can be avoided, and none of us would be spending time (even with the caveat of being on a more bleeding edge) extricating ourselves from it and more on being productive in some way-- possibly even via contributions to our community or one we touch through it.