Yes, look at the void-packages tree (either online, which you can get to it by clicking on the package in the package search page) but even better is to clone the repository yourself, which is really a must if you think you might build anything nontrivial for your system (I try to work outside a distro's PM system as little as possible; the only things currently living in /usr/local on my Void system are a few scripts and small (single-sourcefile) programs. See here (wiki) for quick info, and here (manual) for when you want to actually make use of it (packaging software)
The information you want here is almost always in the template, (only exceptions I can think of would be items distributed as source like dkms) You might find they've got some similarities with Arch build templates, which from what I read also borrows ideas from BSD port systems.
Regarding getting old packages.
My script does that, but you don't want to use it as it is now because the way I set it up will break things that depend on those packages. (right now, it's a proof-of-concept toy)
The most important part is where
xbps-query -f was piped to a file, which was then taken as input by pax to copy the needed files to another location, where you then run xbps-create, supplying your own metadata values. That's the part that I first tried manually, which made me want to script it.
The bulk of the script (and the part that was a real pain) is for parsing out the metadata to pass to xbps-create. What needs to be done is:
- pull the base-64 encoded files from the xbps database so I can re-create the install/remove scripts and other "meta" files for the package manager
- work out naming/versioning... I guess one possibility is to simply use the same packagename and version, and then you'd just xdowngrade to the package and place it on hold to prevent any upgrades (which will have cascade effects, and is the reason holding packages isn't a longterm solution to most problems)
I may or may not actually get to this...
However, for you immediate present and near future needs, a workaround is to make sure those packages don't get updated (don't update gcc!) Again, it's definitely not a viable long term solution, but it can buy some time to breathe and reflect.
One question that remains is whether the problem could be from an asymmetric upgrade of sorts. (by which I mean something in the dependency chain that should be currently built against gcc6 didn't get updated, but that doesn't match up to your report of doing a -u for the whole system)
Don't you just love problems that nobody else has, or can get to the bottom of? (I feel for you there)