> RPM/yum and dpkg/apt are not perfect, but they are vastly superior to ports in every dimension.

After about ten years of experience with ports and apt (and some minor experience with zypper and yum) I have to say that this as well as most other statements you made are wrong.

I broke things with yum and apt, never with ports. Regarding knowing what port installs what. That's indeed possible, the statement that it isn't is wrong. On the port level itself you have PLISTs on the package level you have even more.

> With ports, it is likely you will, over time, end up with multiple versions of some things (libraries, languages, etc.) installed. This is common on Linux, as well, but the ability to determine what is built against which versions, and to be able to keep up with whether, say, an insecure version can be removed without breaking things on the system, is much weaker (non-existent, as far as I can tell).

Wait, what? Have you ever used ports/the BSDs? Actually this particular problem, being able to cleanly decide which version of a library or piece of software I want to use is one of the main reasons for me to use BSD in favor of Debian or CentOS. Actually that was the reason to switch from a Debian/Ubuntu setup to FreeBSD and we never regretted it. The worries about everything related to packages just went completely away with that change. It really is a main benefit of the BSDs in general.

Did you ever have to deal with multi repositories on a Debian based system, maybe using backports, maybe even requiring unstable branches. It can be a horror. One is constantly between software that's too old to compete or unstable or when upgrading sometimes too new. It is an enormous pain and you can keep a team of sysadmins or devops busy trying to work around all the problems that appear when you do that using apt.

Even things like security updates often make their own problems. Especially when these things try to be smart about which services to restart. Either your server restarts while under enormous load and your infrastructure has a giant hickup that may lead to downtime or you update OpenSSL and things remain as they are.

Another problem is how packages often get modified, split, etc. and behave completely different everywhere.

One more benefit of the ports system is configurability. I set up a system like FreeBSD's poudriere, have a simple, global configuration, specifying whether I want documentation with my packages, whether I want Xorg-Dependencies for my command line tools, things like which databases I want to use, but also and that's probably one of the greatest things, whether I want my packages to be built for Postgres, 8.4, 9.2, 9.3, 9.4 or whether I want to use PolarSSL, GnuTLS, OpenSSL, LibreSSL, just with one single option.

The port infrastructure prevents a lot of duplication of work. Many features added to it simply become available for every port there is. You don't need some maintainer to have exactly the same setup and (compile time) configuration as you. That is a huge plus.

Actually many systems like Arch ABS to build packages are basically a ports collection themselves. Many ideas were taken by projects, like the RPM-based OpenPKG. None of them are as powerful as what the BSDs offer, though Gentoo's Portage comes close.

Speaking about reliably rolling back versions. That actually is yet another reason for me preferring ports. It tends to work way easier than trying to do that in apt, at least when you want to do that in a sane/safe way. But to be honest, it is not the thing you need to do on a daily basis.

Another feature is to be able to hack into it, if it really necessary. You have way more, easily accessible possibilities to quickly change something. Try to do that on apt or yum and you will easily end up with a broken system. That's what I consider fragile.

Also your statement about checks on packages is simply wrong. Why wouldn't you be able to? Other than that I wouldn't rely my security on that. Package Managers are no intrusion detection systems. If you use them like that you may want to overthink that approach.