How "stable" are quarterly ports.

Alain De Vos

Alain De Vos

Sometimes when i do a git pull of quarterly ports i have to recompile thousands of ports because of a dependency on some root port that changed from version x to version x_01.
That's not very stable and quiet annoying.
So using poudriere & quarterly i'm in a compilation hell. Compiling and a few days later compiling again.
Sometimes when compilation has ended , i can start compilation again because of changes to ports with lots of dependencies.
Feel free to comment.
 
You mentioned "... because of a dependency on some root port that changed from version x to version x_01": is that the sole reason for needing to "re-compile"? Also: Those changes you mentioned, have you any idea whta kind of changes they are (security "patches" for example)? Just thinking out loud (not a git advanced user): couldn't it have something do to with changed meta file properties (e.g. time stamps), when the contents of the downloaded ports/files haven't changed?

Just to be sure about what we are talking about, what is the actual git command you use for those pulls?
 
I use poudriere in a jail,
then
Code: 
cd /usr/ports
/usr/local/bin/git pull --rebase --autostash
/usr/bin/nice -n 15 /usr/local/bin/poudriere bulk -b "quarterly" -j $JAIL -p $PORTS -f $PACKAGES
 
You need two things:

1) look up what that minor version bump for a certain port actually did. If it was important in your opinion (let's say a security fix) then you have a valid reason to recompile. If the change was needless in your opinion you can discuss that with whoever committed to quarterly and explain your stance. Feedback is always good.

2) a faster computer. Your FreeBSD usage pattern clearly justifies it. I gave some tips for sub-$1000 rigs in a different thread.
 
I'm also using the quarterly ports and for what I do (mixing ports with packages) they are stable enough. For upgrades I'm using ports-mgmt/portmaster and most of the time I'm avoiding upgrading heavy ports (firefox, gcc, llvm, rust, ungoogled-chromium, etc.) and so far this recipe is worked without major incidents in the last 5 years.
 
From the wiki:
 

Attachments

  • 1716665496256.png
    1716665496256.png
    87.2 KB · Views: 43
From Quarterly Branch Ports and Packages:
-- Purpose

A user experience (UX), for port and package installations and upgrades, that is more predictable and stable than the UX for the more dynamic main branch (familiarly: latest).

In essence, changes are limited to:

non-feature updates.

quarterly is the default for FreeBSD-RELEASE versions 10.2-RELEASE and later.

-- Governance

Ports Management Team (portmgr)

-- Aims

Receive, on a best effort basis, merge (cherry-pick -x) commits including, but not limited to:

Security fixes (that may be version updates, or backports of commits)
Build, run, packaging, or other bug fixes
Ports compliance/framework changes.

More precisely:

Any change that is not a version update – unless it is a security update – that, other than the intended change, makes no functional change to the resulting package or software.

Merges from main are limited to the most recent quarterly. Prior branches are not supported; no merges.
Click to expand...

Hmm, excluding security fixes, this reads to me as:
As long as you keep the functionality of a port (=its external behaviour) the same, you are allowed to update a port (i.e. commit changes) and propagate these to the most recent quarterly branch.
Click to expand...

Thus, in effect, as long as you can justify that the changes do not constitute/mandate a (minor) version update, you could completely overhaul the code base of a port and these changes will be merged—midstream—into the quarterly branch. Mainly because
A user experience (UX), for port and package installations and upgrades [of a quarterly branch], that is more predictable and stable than the UX for the more dynamic main branch (familiarly: latest).
Click to expand...
Thus choosing UX predictability and stability as opposed to code base predictability and stability.

Am I interpreting this phrasing correctly?
What is current practice?
 
Just recently switched from HEAD to Quarterly myself as I got fed up with long recompiles of rust (thanks clamav), always good to talk about how folks keep their checkouts in sync, here's how I went about it...

To get the latest quarter...

git clone --branch 2024Q2 https://git.freebsd.org/ports.git /usr/local/poudriere/ports/quarterly/

And while we are in Q2 I'll just keep doing...

git -C /usr/local/poudriere/ports/quarterly/ pull
/usr/local/bin/poudriere bulk -j FreeBSD_14-0 -p quarterly -f /usr/local/etc/poudriere.d/port-list -v

When it gets to Q3, I'll just purge /usr/local/poudriere/ports/quarterly/ and start again doing a checkout fresh then pulls till that Quarter expires.

So far I am only seeing a few compiles as time moves on and all my packages are up to date with those I see listed in freshports.

Bear in mind pkg stats only shows 748 packages being managed by poudriere.
 
Erichans said:
… this reads to me as:

❝As long as you keep the functionality of a port (=its external behaviour) the same, you are allowed to update a port (i.e. commit changes) and propagate these to the most recent quarterly branch.❞

Thus, in effect, as long as you can justify that the changes do not constitute/mandate a (minor) version update, you could completely overhaul the code base of a port and these changes will be merged—midstream—into the quarterly branch. …
Click to expand...

Probably not.

Comparably (also from the wiki): new ports are normally not merged to quarterly.
 
Cath O'Deray said:
[...] Comparably (also from the wiki): new ports are normally not merged to quarterly.
Click to expand...
That seems rather obvious to me. In its essence the quarterly branch is a quarterly snapshotted version of the main branch (aka "latest"). A newly added port to the main branch constitutes a jump from an absence of functionality to the existence of functionality, a jump from "no version at all" to "a version".
 
Erichans said:
That seems rather obvious to me. …
Click to expand...

It surprised me, when sysutils/hammer2 (no dependencies) was added to the tree.

I do understand reticence, if a new port does have dependencies.

Where there's no dependency: refusal to build a package seems peculiar, to me.
 
Alain De Vos said:
So using poudriere & quarterly i'm in a compilation hell. Compiling and a few days later compiling again...
Feel free to comment.
Click to expand...
I build all of my packages with poudriere and quarterly ports. It can be burdensome as you say, because poudriere insists on building in a functional way (if a dependency changed anywhere in the tree of dependencies the package is rebuilt -- it's inputs have changed). I like the whole tree builds very much so I won't complain about the "compilation hell". At least when a build is complete I know that every package represents a clean build of that "ports tree" as it currently exists on my computer.

It isn't actually much of a burden for me because I trust quarterly ports to be asymptotically approaching perfection, so that a couple of weeks after the quarterly is branched I build my packages for the new quarter. I could use those packages for three months without any changes and be very happy. I do watch freshports.com and if I see an update to the quarterly ports that strikes me as important I may update my ports and re-run the bulk build.

I never update my packages more often than once every 4 to 6 weeks (and feel foolish updating stable quarterly ports that often).

Everyone is updating everything too often. Get it running. Stop compulsive updating. Be happy!
 
In my opinion an invulnerable system can not be achieved by chasing "security updates" and I mostly ignore them. We are using software that for the most part has been continuously "improved" for at least a decade. Most packages have had hundreds or thousand of updates since their 1.0 release. If they are still buggy and vulnerable then at least we have proved that they have always been and will always be buggy and vulnerable. (I realize that you may draw a significant difference between "vulnerable" and "known attack vector" but my knowledge of the vulnerability is probably not significantly correlated with the attackers's knowledge of the vulnerability).

I do react to vulnerabilities by migrating entirely away from software that has a history of security flaws.

Stop updating. Be happy.
 
garry said:
I do react to vulnerabilities by migrating entirely away from software that has a history of security flaws.
Click to expand...
So, you've gone back to clay tablets? Every bit of software has a history of security flaws.
 
You must log in or register to reply here.
Back
Top