Users using binary packages cannot avoid installing some ports from source since many ports cannot be packaged due to licensing restrictions, e.g. audio/lame, sysutils/fusefs-exfat, etc.
To avoid dependency version mismatches, users must ensure that their ports tree is the same branch as their pkg repo and if using "latest", that both are updated regularly.
Currently, pkg.conf only designates "latest" or "quarterly" and there does not appear to be a way to easily query which quarterly branch is currently in effect. Guessing based on today's date would give a close approximation and probably avert most issues, but I don't believe it's possible to predict exactly when "latest" switches to a new quarterly branch.
Add a subcommand to "pkg" that displays the ports branch from which their pkg repo was built, such as "2020Q2" or "latest", e.g.:
prompt: pkg branch
Using this output, it would then be easy to ensure that their ports tree matches the pkg repo.
I'm happy to help with coding and testing, but we should have a discussion about the best approach to this problem before spending time on an implementation.
We could also attack this problem from the opposite angle by creating a ports branch called "quarterly" that's kept precisely in sync with the latest quarterly packages. I.e. it would switch to a new quarter at the same instant the new quarterly packages come online, not the moment a new ports branch is created.
Then a routine svn update alongside pkg upgrade is all users would ever have to do to ensure consistency.
If we did that, I'm not sure whether a "pkg branch" feature would still be interesting.
(In reply to Jason W. Bacon from comment #0)
Just noticed a typo in the original post. I meant to write:
I don't believe it's possible to predict exactly when "quarterly" switches to a new quarterly branch.
Well, it is easy to predict when quarterly switches branches.
As the process is automated and the package build process always uses the latest branch, the packages switch a couple of days after a new branch is created.
(In reply to Mathieu Arnold from comment #3)
That's only approximate, since we don't know how long the package builds will take, and that can vary a lot from quarter to quarter due to numerous factors. Any kind of guessing leaves a window open where the ports tree and pkg repo could be on different quarters, causing failures due to incorrect dependency versions.
I think we really need either a simple and reliable way to *detect* when the pkg repo has switched to a new quarter, or a ports branch that's reliably kept in sync with it behind the scenes.
I consider FreeBSD's ability to install via either binary packages or from source to be a major advantage. However, it introduces additional problems like this one that I think we have to address to keep users from experiencing unnecessary aggravation.
As of now, the installer defaults to head ports and quarterly packages, which is certain to cause problems unless the user manually intervenes. Most new users aren't aware of this and many will simply write FreeBSD off as a viable OS when they encounter such problems. Installing a quarterly ports branch as of the release date won't solve the problem, because it won't be automatically updated to the next quarterly branch along with the pkg repo.
If the branch tag is encoded in the pkg repo, we would at least have a reliable way to automatically keep quarterly ports and packages in sync.
Taking the other approach, a quarterly ports branch could be automatically synced with the latest quarter upon completion of quarterly package builds.
One problem with creating a "quarterly" ports repo is that bulk builds may complete at vastly different times for different architectures, so we'd need separate repos for amd64, i386, powerpc64, etc. in order to sync them at the moment a bulk build completes.
Going back to the "pkg" query approach, a very simple solution would be to add an entry something like
ports_branch = "2020Q2";
to meta.conf, e.g. http://pkg.freebsd.org/FreeBSD:12:amd64/quarterly/meta.conf. This would make it trivial to determine the ports branch behind the quarterly packages with or without augmenting the pkg command.
I'm guessing this file gets updated upon completion of a bulk build. If not, I think it easily could, or we could add a separate file to indicate the ports repo.