Ports or Packages?

Do you compile ports, use binary packages, or mix both?

  • Total voters
    38
I vote for ports, I did not leave GNU/Linux just to end up having to install audio/pulseaudio alongside www/watefox when it is not necessary.
Do I recommend using only ports, as I do? Unless you are a fanatic like me, no. For instance, in the 2026Q4 branch I cannot compile emulators/mame or www/qt6-webengine (with errors after compiling for over an hour), www/waterfox complains that the installed version of lang/rust is too old to build it (you have to install lang/rust-nightly and add it to your make.conf), net-p2p/amule fails in the same way as in this already-fixed bug (it appears that the dependency security/cryptopp has changed to security/cryptopp-modern, which does not provide the configuration options that previously allowed for resolving the bug), x11/foot won’t begin to compile because dependency x11-fonts/fcft keeps failing its source code checksum verification, even though the latest update claimed this issue had been resolved, there are applications that still use qt5 even though a qt6 version is available and recommendable (print/lyx, audio/flacon, security/keepassxc -though in the last case the stable qt6 version was released only a few days ago) and I encounter an error when compiling x11-toolkits/qt5-gui which prevents me from installing most programs that use qt5.
Please do not take this as a criticism of the FreeBSD ports maintainers: it is a massive job to take an application, often that was not designed with FreeBSD in mind, and adapt it for a multiplatform system with several active branches and with errors that affect dependencies, not the application you are maintaining. I truly applaud their work 👏. I am simply pointing out that if you intend to rely exclusively on ports, you should be prepared to deal with some hurdles along the way.
 
LoganGreystone Well, that's one of the advantages of a complete package that's put together for you and known to work. Ports is like Linux, pulling things in from all over in various stages of build that may work individually but might occasionally not all work together.
 
T-Aoki said:
Subpackages? Needs buildable at once, though.
arrowd@'s document would help understand the differences between slave ports, flavors, options and subpackages.
Click to expand...
Didn't knew about subpacakges in FreeBSD up to now, thanks for the mention.
drhowarddrfine said:
You're asking for custom packages--cause everyone will want something different--without having to build the package and that can't happen anywhere.
Click to expand...
Not necessarily, what I want is for packages to react to other packages. Continuing the example of imagemagik, it's built with support for everything, but for example the jpegxl support is only available if both imagemagic-jpegxl and libjpegxl are installed.
It probably depends on runtime detection or at least on failing graciously when a required dependency is not available. So maybe subpackages is part of what I wanted?
 
drhowarddrfine said:
That's what I said.
Click to expand...
maybe I understood what you wrote wrongly. what I read was that custom packages aren't doable because everyone wants something different. To this I responded that I'm fine with packages built for everything (basically what is now), it would be nice though if would be possible to split support (where possible) and rely on runtime detection or gracious errors to support optional functionality.
 
You must log in or register to reply here.
Back
Top