Time lag between official ports and packages

blazingice

blazingice

My understanding is that the main/latest branch of packages provided by FreeBSD is built from ports.
Is there a time lag between something appearing in ports and then in the main/latest branch of packages? Obviously there will be some build time, depending on how long it takes the servers to build all the ports, but I am curious if this is a pure mechanical process, or receives some internal curation in a similar way that the quarterly branch does?

An example: KDE5 5.27.0 seems to have made it into the ports from 14 Feb, but the version in the latest/main package shows 5.26.5 as of 19 Feb.

Will we expect soon the latest version of 5.27 in the latest/main branch of packages? Any idea how long it may take? Is there a way of tracking the build time of packages? I have had a look at Package Status - FreeBSD, but find it difficult to track the progress of a specific package.
 
Uhm, it's much simpler than you seem to think:
  • Packages are built from ports, always!
  • The process is automated, "latest" repo is built from the "main" branch, "quarterly" from the latest quarterly branch (there's one per quarter)
  • It takes a few days for a builder to build the next iteration
Talking about "curation", this happens on the source level. Quarterly branches are snapshots of main. If, and only if a change on main fixes a security issue or another severe bug, it's also applied to the latest quarterly branch.

edit:
blazingice said:
I have had a look at Package Status - FreeBSD, but find it difficult to track the progress of a specific package.
Click to expand...
Packages aren't built individually. The builders periodically fetch their respective source branches (of the whole ports tree) and rebuild the whole repository (of course only what changed, including dependencies). On the page you link, you can filter branches, FreeBSD versions and architectures to find the bulk build you're interested in, then you'll have a link to see the progress of that build (requires IPv6).
 
Take a look at this build: https://pkg-status.freebsd.org/builds/default:default:131amd64:9d6358b286b5:beefy16

You can see that it started on 2/18 and took 80 hours.

The other really useful bit of info on the build pages is that the build ID corresponds to the git commit in the ports repo it's building: https://cgit.freebsd.org/ports/commit/?id=9d6358b286b5

That's particularly useful if you use poudriere and want to install pre-built packages where possible. You can check out the ports tree at that specific commit, run poudriere bulk -b latest and your ports tree will match the latest build. You end up only building ports that you've customized in some way.
 
I am still missing something here!

According to the above example (https://pkg-status.freebsd.org/builds/default:default:131amd64:9d6358b286b5:beefy16) the most recent package built should have been ready by now, including the recent version of KDE5 that is already in ports. However the latest branch of package as of 23 Feb still shows 5.26 as the latest version of KDE5 rather than 5.27. So there seems to be a bigger time lag than just the built time of 80 hours given above, hence my initial question.
 
blazingice said:
So there seems to be a bigger time lag than just the built time of 80 hours given above, hence my initial question.
Click to expand...
It can also take a couple of days to sync all the repositories to the mirrors.
 
Yeah, and there's noise all over the Internet that 5.27 is gonna be the last Plasma5 release, maybe a few bugfix releases later this year, but Plasma6 development is taking center stage. An educated guess on my end has me thinking that Plasma6 is not gonna arrive on FreeBSD until 14.0-RELEASE.
 
astyle said:
An educated guess on my end has me thinking that Plasma6 is not gonna arrive on FreeBSD until 14.0-RELEASE.
Click to expand...
You know they're not technically related (meaning ports are pretty much independent from base releases)?

If this is just a guess about "coincidence on the schedule", well, it's quite early for that kind of thing: There's no upstream release schedule for plasma-6 yet.

Normally, the KDE team of FreeBSD ist pretty quick adopting new upstream releases. 5.27 was unusually delayed because of some hard-to-understand (and blocking) bug during startup of the desktop.

The delay between upstream release of plasma6 and availability in FreeBSD ports will pretty much depend on the unforseeable problems encountered during porting :cool:
 
patmaddox said:
Take a look at this build: https://pkg-status.freebsd.org/builds/default:default:131amd64:9d6358b286b5:beefy16

You can see that it started on 2/18 and took 80 hours.

The other really useful bit of info on the build pages is that the build ID corresponds to the git commit in the ports repo it's building: https://cgit.freebsd.org/ports/commit/?id=9d6358b286b5

That's particularly useful if you use poudriere and want to install pre-built packages where possible. You can check out the ports tree at that specific commit, run poudriere bulk -b latest and your ports tree will match the latest build. You end up only building ports that you've customized in some way.
Click to expand...
Not sure, how to understand that. I've checked the latest tree and qt6-webengine that is big haven't updated upon dependancy for 4 days. So either search, then checkout git tree on old commit, then rebuild what's already has been built with the new dependancy, or wait some undifinite time for official build.

There is the same situation with qt5-webengine and re2 lib.

Maybe checkouting for tree before dependency bump will do, but that's a manual work.
 
Last edited:
If (disclosed) ports tree and official pkgs are mandated to be 100% in sync, FreeBSD project should completely change the server framework for ports/pkgs. I don't think it a good thing, but write up example below.
Yes, it's completely nonsense. But requiring pkgs available when appears on ports, this nonsense should be mandatory, my guess. Thus, non-realistic.

First of all, master ports tree SHALL be made available for committers and build clusters only. Stop guest access completely.

Once any of the updated (on master) pkg is built fine, builder reflects the commits on master for successful build only to freely-available official ports git server immediately.

Theoretically and technically, it would be possible. But this clearly causes fatal delay of feedbacks from possible developers without commit bits or users (like me) who actually builds and runs the pkg on hand.

Moreover, if the maintainer of an updated ports is not a committer, the maintainer cannot notice breakages especially when its dependencies are updated after the maintainer submitted patch, because in this situation, commit to master SHALL not appear on bugzilla nor phablicator until it is reflected to official disclsed repo to avoid confusion of non-committer users. Nonsense. Quite nonsense!

So my conclusion is that the delay must be patiently accepted.
 
You must log in or register to reply here.
Back
Top