Best way to manage ports?

[patmaddox]

emacs has a man command, makes it super nice to browse local man pages

 

[cy@]

I run my 14-current instances from pkg without problems. I voluntarily use a self-compiled chromium, however.

Agreed. I also use 14-CURRENT. I have a couple of poudriere 14-CURRENT jails, one for amd64 and the other for i386.

I have had no problems or issues with the packages built in the jails, the jails themselves, nor with 14-CURRENT, which has been extremely stable -- which BTW contains various patches currently being tested prior to commit.

In addition to this my src and ports trees also contain patches I do not intent to ever commit.

OTOH, the standard advice to use one of the -STABLE branches is best for most people, unless of course a person wants to tinker and is willing to accept the odd mishap, like something not working as documented, or the rare crash. I'd like to add that the quarterly ports branch is certainly more stable than the ports main branch.

For most people I'd recommend binary O/S updates and binary packages (instead of ports). I've been using 13-RELEASE with binary packages at $JOB (since I don't have the time to tinker at $JOB, replacing a Fedora VM with a FreeBSD VM as my goto git/ansible platform at $JOB) and have been totally satisfied with freebsd-update and pkg upgrade in that environment. FreeBSD has come a long way since the "old days."

 

[Alain De Vos]

Quarterly-ports have the advantage that you have the do less rebuilds. Mostly they are just security-patches or alike within a quarter.

 

[Erichans]

When running -CURRENT, you do need to do that.

What makes you think so?

Because -RELEASE & -STABLE versions have a locked down ABI while the -CURRENT ABI can change. Packages in FreeBSD repositories are built against ABI of supported -RELEASEs. Also KAPI for kernel modules in the ports collection (very few), like amdgpu in graphics/drm-kmod to be matched to the LinuxKPI part in a -CURRENT kernel.* Based on the responses later on in this thread, it could very well be that ABI changes in -CURRENT happen rather infrequently. If that is the case I think you could use remote binary packages and my "always" need to is too strong.

Am I wrong about this?

___
* that is relevant here I think (RX 6600 of the OP), and LinuxKPI code is in flux—based on the number of commits recently.

 

[TheDantee]

Because -RELEASE & -STABLE versions have a locked down ABI while the -CURRENT ABI can change. Packages in FreeBSD repositories are built against ABI of supported -RELEASEs. Also KAPI for kernel modules in the ports collection (very few), like amdgpu in graphics/drm-kmod to be matched to the LinuxKPI part in a -CURRENT kernel.* Based on the responses later on in this thread, it could very well be that ABI changes in -CURRENT happen rather infrequently. If that is the case I think you could use remote binary packages and my "always" need to is too strong.

Am I wrong about this?

___
* that is relevant here I think (RX 6600 of the OP), and LinuxKPI code is in flux—based on the number of commits recently.

I was first using the 5.13 driver from dumbbell but have moved to 5.14 recently found here - https://github.com/freebsd/drm-kmod/pull/226 hoping it makes it's way to native 14 and then 13.2 eventually. What would be really nice is iGPU support for the 7000 series (Linux 6.1 I think) or even modern intel wifi chipsets for devices like the framework laptop. I think it does change the ABI as it requires me to install a new kernel to use the drivers. Hardware support is why I started donating to FreeBSD Foundation in the first place it simply needs to catchup to be considered by alot of people. It's a shame companies don't offer more support in the way of GPU Drivers and what not.

 

[SirDice]

I think it does change the ABI as it requires me to install a new kernel to use the drivers.

Some changes with the DRM driver might need some updates to the LINUXKPI interface. That's the part that's included in the FreeBSD kernel. The linuxkpi interface is also used with the new Intel Wifi 6 drivers and could potentially be used for other drivers. The linuxkpi isn't complete though, it just has the bare minimum in it to be able to use the DRM and wifi driver code.

 

[astyle]

What would be really nice is iGPU support for the 7000 series

This rang a bell for me... I remembered doing some research on exactly that back in October of '22... and it looks like the Ryzen 7000 chips (not to be confused with RX 7000 dGPU) have RDNA2 graphics, which is Navi21, which is actually supported by the sienna_cichlid driver provided by the amdgpu.ko in the graphics/drm-kmod port... and one of my own threads in here has some pretty good links: Thread sienna_cichlid-driver.86670. That thread talks about lack of support for newer stuff, but it looks like since then, the situation has actually improved, just click on the links to FreeBSD's cgit repos.

 

[TheDantee]

This rang a bell for me... I remembered doing some research on exactly that back in October of '22... and it looks like the Ryzen 7000 chips (not to be confused with RX 7000 dGPU) have RDNA2 graphics, which is Navi21, which is actually supported by the sienna_cichlid driver provided by the amdgpu.ko in the graphics/drm-kmod port... and one of my own threads in here has some pretty good links: Thread sienna_cichlid-driver.86670. That thread talks about lack of support for newer stuff, but it looks like since then, the situation has actually improved, just click on the links to FreeBSD's cgit repos.

Interesting I thought it was added in 6.1 (according to Phoronix) I'd have to test loading on my iGPU I'm back to running OpenBSD atm torn between that and FreeBSD moving forward both are great! Maybe I will wait for 13.2 to test. I was thinking I could downsize my build to like a Skyreach 4 Tini or something from my current Sliger S620 since I don't really need the GPU much for what I mostly play, although the iGPU is quite the downgrade from even something like my 6600 XT.

 

[bsduck]

Maybe I will wait for 13.2 to test.

Given that GPU drivers and related firmware are distributed as ports rather than being part of the base system (unlike OpenBSD), it should not make much of a difference whether you're using 13.1 or 13.2.

 

[TheDantee]

Given that GPU drivers and related firmware are distributed as ports rather than being part of the base system (unlike OpenBSD), it should not make much of a difference whether you're using 13.1 or 13.2.

DRM-Kmod port hasn't been updated so...