Bug 245667

Comment 1 Jason W. Bacon 2020-04-17 13:27:48 UTC

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.

Comment 2 Jason W. Bacon 2020-04-17 13:31:06 UTC

(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.

Comment 3 Mathieu Arnold 2020-04-17 14:16:45 UTC

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.

Comment 4 Jason W. Bacon 2020-04-17 17:31:19 UTC

(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.

Comment 5 Jason W. Bacon 2020-04-19 16:08:05 UTC

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.

   JB

For what it's worth...

I've been using FreeBSD for a long time since Version 4 or perhaps V3.

I always assumed that packages and ports were linked automatically and that any dependency issues were just a bug.

I ran across this bug report via a thread Jason started in the ports and packages forum and I found that thread after reading in the beloved handbook that if I wanted to use both ports and packages then I had to ensure they were working from the same branch.  I quote:

"If the Ports Collection and pkg must be used in conjunction, then be sure that your Ports Collection and pkg are on the same branch release of the ports tree."

In fact it would be a trivial system indeed that did not absolutely require both systems - it is one of the great features of FreeBSD.

9/10 times a package will suffice and using packages for install is far faster than ports so it is compelling to go that way so most of my little server installs indeed use packages now though I started with only ports.   

Only a trivial server with limited services would not require some kind of modification to one of the package default compile options.   This seems to be a trend (i.e. the notion of a VM or Container so support a single application) but there are still little servers like mine that support quite a variety of services like an old mainframe and do it quite well.    

It would be a shame to have to go back to ports only or to have to manually compile each application outside of a maintained tree.

Comment 7 Jason W. Bacon 2022-01-02 17:06:40 UTC

FYI, I recently made an improvement to auto-pkg-branch (part of sysutils/auto-admin) for quarterly packages.

Rather than use today's date as it did before, it checks the time stamp on meta.txz:

fetch -o $tmpfile http://pkg.freebsd.org/FreeBSD:$major:$arch/quarterly/meta.txz        
mod_time=$(ls -l -D '%Y-%m' $tmpfile | awk '{ print $6 }')

This provides an account of when the packages were likely last updated rather than assume they're updated every quarter.  In fact, quarterly packages for 13.0-RELEASE powerpc64 were never published for 2020Q4, so this improvement prevented my ports tree from being knocked out of sync with the package set.

This is still a hack, though, since it's probably possible for meta.txz to be touched without the packages actually being updated to the current quarter.

It would be really nice if we had an officially supported method for determining the packages branch.