Theoretically.... most people coming to FreeBSD at a moment will choose ports, because you come to FreeBSD to be free to "cook" your system in as many way you want.
And don't expect to combine ports and standard packages....this point is regularly discussed in this forum. From the moment you choose custom options from ports, you affect the chain of dependencies, so at a moment you will break the standard package system. In fact, on package update the system will attempt to rollback any customized port to standard packages.
But.... it will also depend on your hardware.
If you run old hardware, maintaining a port system can be painful.
Le'ts take an absurd and stupid example....
You run a Raspberry and you want to compile chromium.... it could take, let's say 7 days, as chromium is well known here to be probably the longest port to compile.
That's also for saying... it depends on what you want to compile.
If you intend to install a light headless server, so with no desktop, with some hardware more powerful than a Raspberry... yes, you can choose ports and "cook" your system.
Other scenario... your hardware is light, very light.... but you absolutely need some custom options for some ports.
The solution is to use "poudriere" on another FreeBSD server running with a good processor which will compile the ports and build custom packages in a http, ftp, repository.
Your light server will install ports through you precompiled custom packages... Custom packages have exactly the same format as the standard packages... they just differ in the options, and so that modifies the chain of dependencies.
Addendum :
------------
Please note that
ports-mgmt/portupgrade tool can intelligently combine ports and standard packages if possible.
The following command
portupgrade -aRP means :
- a : update all installed port
- R : before updating a given port, update dependencies before if required. What we call backward dependencies.
- P : use package if possible
So portupgrade will download and install standard package for a given port, rather than building it, if :
- the given port "A" is set to its default options
- all dependencies (so running dependencies and building dependencies) of port "A" are set to their default options
In any other cases, portupgrade tool will build the port "A"
In fact, if you install a little system with only a few ports with custom options, generally you can combine packages and ports through the "portupgrade" tool
If you install a bigger system, as a desktop, this implies a bigger number of ports and so this is creating a very complex chain of dependencies. So there are only few chances for "portupgrade" to install standard packages.
It also depends on the level of dependencies. If you customize essentials packages as Perl, Python.... automatically it affects number of forward packages.
If you just customize an end user application as "firefox", there is generally no impact on the chain of dependencies as Firefox is rarely a backward dependency.
Anyway, when I choose "port", I personally don't try to combine package, so I never use the "P" option with "portupgrade", because any failure in building a port "A" may reveal related backward dependencies issues.
So first you generally rebuild the dependencies... and you rebuild port "A"
If "portupgrade" installs package "A", it will not warn you on such issues and so you may find the program not working... with no explanation
In a canonical way, if you want to secure a process, if you update "port A", you should also force rebuild all ports that have "port A" as dependency, what we call "forward" dependencies, corresponding to "r" option in "portupgrade" tool.
But this is only theoretical, because updating a very low level package as python, perl ... should theoretically result in a full system rebuild.
For the common user, this is simply not possible as his computer would be used 90% of its time to build, build and always build packages.
This is possible for little systems with few packages, or for some professionals who have powerful "poudriere" dedicated machines, focused on building custom packages, and so able to rebuild all installed port, and serve them in a repository in just a few hours per day.
For any standard user... he takes the risk to not rebuild the forward dependencies, and so do that on "request" when a problem occurs
If you install a big desktop as Gnome, KDE5.... rebuilding a full system can take several days speaking of standard desktop machines, this is the reason why "theory" is not applicable for most of us.
