That particular case - upgrading everything - is actually supported pretty well. Of course, there's the distinction between the base system and app packages - the base still needs to be upgraded another way (freebsd-update).
It's the much more useful case of upgrading complete subgraphs of package dependencies that still wasn't implemented when I last looked at it a year ago.
If you have application packages A1 and A2 installed, and a library package L on which both of them depend on, then if you upgrade A2 to a newer version which requires (and is linked against) a newer version of package L, pkgng will simply not upgrade both L and A1. The pkgng devs simply declared this to be out of scope.
For a time, pkgng (now just "pkg" as it's the only one) looked like it could be the best thing since sliced bread, only for the devs to arrogantly dismiss the most common dependency-related operation used in practice. It's the single biggest issue which turned me away from FreeBSD, since I don't want to write package manager code, don't want to maintain my own package repos, and don't want to track "snapshots" (i.e. 6-months old "freezed" package repos, without security updates) which are the three "workarounds" proposed to me at the time.
This is important because FreeBSD's ports and packages are on a "rolling release" model, i.e. often (daily/weekly, depends on the maintainer) updated to the latest upstream version, so the lack of complete subgraph package upgrades regularly leaves you with broken apps.
It's the much more useful case of upgrading complete subgraphs of package dependencies that still wasn't implemented when I last looked at it a year ago.
If you have application packages A1 and A2 installed, and a library package L on which both of them depend on, then if you upgrade A2 to a newer version which requires (and is linked against) a newer version of package L, pkgng will simply not upgrade both L and A1. The pkgng devs simply declared this to be out of scope.
For a time, pkgng (now just "pkg" as it's the only one) looked like it could be the best thing since sliced bread, only for the devs to arrogantly dismiss the most common dependency-related operation used in practice. It's the single biggest issue which turned me away from FreeBSD, since I don't want to write package manager code, don't want to maintain my own package repos, and don't want to track "snapshots" (i.e. 6-months old "freezed" package repos, without security updates) which are the three "workarounds" proposed to me at the time.
This is important because FreeBSD's ports and packages are on a "rolling release" model, i.e. often (daily/weekly, depends on the maintainer) updated to the latest upstream version, so the lack of complete subgraph package upgrades regularly leaves you with broken apps.