STABLE users: How often do you update? What packages need to be built from source?

[bilegeek]

1.) What is your personal update schedule? Do you use Jails, ccache or distcc? Do you use your computer for other stuff during compilation? Do you restrict the CPU/RAM it takes?

2.) According to my research: the STABLE world itself needs to be rebuilt from source every time, and obviously the graphics drivers or any other kernel modules need to as well. Aside from that, most pre-compiled packages should work.

However, I've read a few other non-kernel-module packages dealing with nitty-gritty functions need to be rebuilt from source, but I was unable to find the particulars IIRC. What packages could these be? Are there any YOU specifically need to do? If so, do you hook in Poudriere so they compile after buildworld is complete? Any hangups with the Linuxulator packages in particular?

3.) Is STABLE set up to do a world snapshot before the update like freebsd-update, or do you have to roll your own?

I know RELEASE is the better option for 95% of use-cases, but I'm still curious about STABLE.

 

[SirDice]

1) once or twice a month. Or when I happen to be working on something.
2) Yep, kernel modules should always be rebuilt, just to be on the safe side. sysutils/lsof comes to mind. It uses certain kernel structures, and those could change. But I've set up a poudriere build server and build a complete package set using a release(7) image I made from my -STABLE host. So I don't really pay attention, everything I need is rebuilt anyway.

3) you'll have to do this yourself.

 

[mer]

It's been a while since I've tracked STABLE but one thing I made sure to do was subscribe to the mailing lists and actually pay attention to the commit messages. Why? Sometimes you'd see a message about a crash or weird thing and then you need to pay for a commit addressing that.
Aside from that, about once a month.

But that was because I was using my system for other work, not doing FreeBSD development. So that leads into "why are your tracking STABLE". If it's "stuff in STABLE makes my hardware work and it hasn't been pulled into RELEASE yet" that is legitimate but so is "Because STABLE is almost bleeding edge and I'm scared to run CURRENT"

 

[bilegeek]

sysutils/lsof comes to mind. It uses certain kernel structures, and those could change. But I've set up a poudriere build server and build a complete package set using a release(7) image I made from my -STABLE host. So I don't really pay attention, everything I need is rebuilt anyway.

So outdated packages aren't an issue for you. Nonetheless, I want to ask: do you know off the top of your head of other non-module packages that need this treatment like lsof does? Would you recommend recompiling anything in sysutils just to be safe?

It's been a while since I've tracked STABLE but one thing I made sure to do was subscribe to the mailing lists and actually pay attention to the commit messages. Why? Sometimes you'd see a message about a crash or weird thing and then you need to pay for a commit addressing that.

I'm unfamiliar with the term: by paying for a commit, do you mean waiting for it to be sorted out, or applying a fix manually, or something else?

 

[mer]

I'm unfamiliar with the term: by paying for a commit, do you mean waiting for it to be sorted out, or applying a fix manually, or something else?

Sorry, I needed more coffee on that before hitting submit.

I meant "watch the mailing lists for people reporting problems, then watch the commit lists to see when the problem is fixed".

"...then you need to pay attention for a commit addressing that"
I forgot a word.

 

[SirDice]

Nonetheless, I want to ask: do you know off the top of your head of other non-module packages that need this treatment like lsof does?

Nothing I can remember, as I said, I rebuild everything anyway so the update of the base OS gets paired with updating ports/packages. If a port requires the (kernel) sources to be present in order to build it, that's usually a good indication.

 

[T-Aoki]

Aside from that, most pre-compiled packages should work.

Some ports could check for OSVERSION (comes [maybe indirectly] from /usr/src/sys/sys/param.h) when they are built and if it's sufficient, enable some features depends on the version.
As official binary packages are built against oldest supported release per branch (means, packages for stable/14 and 14.1-Release are built using 14.0-Release), if you need such a functionality, you need to build it yourself.

Any hangups with the Linuxulator packages in particular?

It depends. If the package requiring Linuxulator depends overly deep on specific versions of (any of) Linuxulator kernel modules, it could crash.
But if the (original Linux apps of the) port is programmed and built with good enough manner for installed Linuxularo (still defaulted to c7), would run OK. So it depends.

And I'm building latest stable branch (currently, stable/14) basically weekly.
But building ASAP if there are any fixes for CVEs or other problems I've bitten.

Note that "problem" here includes the lack of fuctionality. Not only actual bugs.