> 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.
"Also your statement about checks on packages is simply wrong. Why wouldn't you be able to?"
Because you couldn't until quite recently, as far as I know. As far as I can tell signify, which seems to be what enables signed packages and file signatures, shipped with OpenBSD 5.5. My knowledge is out of date...but if you've been using ports for 10 years, you should remember the time when it was not possible. You should also remember a time when most of my complaints were true, even if they are not, now.
It does appear that my knowledge on the subject of OpenBSD ports is out of date, and I'm sorry for spreading misinformation on several points above. It wasn't my intention to simply trash talk ports...I've been hoping someone would fix it for decades, but, it's only recently (in the last ~5 years) actually started to happen. I apparently just wasn't paying attention when it did.
"Package Managers are no intrusion detection systems. If you use them like that you may want to overthink that approach."
I've done a lot of post-intrusion detective work. On a system that does not have an IDS, it's awesome to be able to compare the installed packages to a known-good RPM or deb. It's more complicated than simply "rpm -V", but not much more, and it can be done without having an IDS configured before the intrusion happened. I can see how if your packages were built custom for the system, this would not be useful (you couldn't verify against a known good version from the web, as it would be unique to your system).
But, it's also useful for non-security purposes. Dumb mistakes, like permission and ownership.
I'm glad pkg_check adds these features to OpenBSD ports.
"Deal with" multiple respositories? That's a completely normal and expected configuration, and not something you deal with.
You don't describe your experiences in detail but it sounds like if you have snowflake requirements where you need to track up-upstream closer, that you're better off building the source debs.
The part where you write off verification checks as also sounds like it is based on a misunderstanding. It is something you do for audit requirements, not something you "rely security on". It is something most professionals would have come into contact with at least once.
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.