9 ms·

OpenBSD ports are more than just a Makefile

76 points by fcambus 12y ago

SwellJoe 12y ago
Edit: I was wrong about OpenBSD ports on several counts, it seems. OpenBSD seems to have corrected several omissions in package management that I've seen in the past; some of these changes seem to have come recently, in version 5.5. I'm reading docs now to see which of these issues have been resolved. Lest anyone be misled into believing ports is comparable to yum or apt...it is not. With ports it is not only possible, but likely, that you will end up with upgrades to some software that can break other pieces of your system, because the dependencies often do not account for things, like compile flags, which can be changed by the user at install time. This leads to a very fragile system a couple years down the road, after a bunch of upgrades and new software installation has occurred. This isn't theoretical; I've seen it happen more often than not in my very limited use of the ports system...it is avoidable, but it is not obvious or well-documented how to avoid it, and adds not insignificant costs to maintaining your systems. With ports it is not possible to verify that the files installed by the port match what was originally installed. This can be useful for security purposes (i.e. has the ps command been tampered with?) or for troubleshooting purposes (i.e. did someone install a program from a source tarball over the original package, or did permissions/ownership change?). Edit: I was wrong on this one. pkg_check verifies package contents against checksums, which is comparable to rpm -V or debsums. With ports, it is not possible to reliably roll-back to a prior version in-place (i.e. without uninstalling everything, and then reinstalling it). 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). OpenBSD has many fine qualities and very smart people working on it, and I don't think it's the dumbest idea ever to use it. But, ports is simply not a sufficient answer to the package management problem. RPM/yum and dpkg/apt are not perfect, but they are vastly superior to ports in every dimension. FreeBSD now has pkgng which is very much a move in the right direction, and it would be definite progress for OpenBSD to adopt it. Note that providing binaries or not is not on my list of complaints about ports, above. Somehow, in every conversation about ports failings as a package manager, there will always be people talking about binaries, and how you can totally install binaries with ports and so there's no reason to not like ports. I find it annoyingly time-consuming to build everything from scratch, but it's not a deal-breaker. Providing binary packages is not why apt and yum are vastly superior to ports.
- tech-no-logical 12y ago
  I have little experience with compiling from ports myself (and that was mostly on freebsd), so I cannot really comment on that, but I've used the pkg_* system for years and have yet to run into serious problems like versioning-hell or pkg's breaking. dependencies are normally well resolved when (de)installing pkg's. even upgrading works pretty well for the most part. I agree that the package management could be better, but as far as I can tell it isn't as bad as you suggest as long as you stick to the official prebuilt packages. or is it different when following -current ? I usually stick to releases and only patch major bugs.
  - derefr 12y ago
    This is like saying [some database] isn't as bad as you suggest as long as you aren't at the scale where you need distribution. The whole point of a package management system is how it handles the complex edge cases, not the simple linear accept-the-defaults cases. Apt, for example, knows how to consume variant packages from alternate sources and then upgrade back into mainline—but also allows the user to specify (with a "pin") that they prefer to continue on the alternative even if it's older. Apt also has an "install from source" system where the source package gets baked into a binary package within a chroot container on the installing system, and then that package gets installed. That package is then like any other package on the system, and can be cleanly removed, or upgraded from into a newer upstream release, etc. These are important features. They're not important for j-random-user, but they're important to distribution maintainers, and to sysops who have to, for example, apply temporary hotfixes to specific packages on their production machines until the distribution ships those same fixes, at which point they want to revert to upstream.
    - Mordak 12y ago
      It's kind of too bad that this thread started off the way it did, because there is now a bunch of misinformation in it. The OpenBSD ports system makes binary packages (and then installs them). Those binary packages are managed by the pkg_* tools, which allow users to install, verify, upgrade, delete, etc., packages. The binary packages are available on the mirrors if you don't want to compile them yourself. You just 'pkg_add <package>' and you're good to go. This is actually the recommended procedure, and users are discouraged from using ports unless they really need to. > Apt knows how to consume variant packages from alternate sources and then upgrade back into mainline... If someone else builds a package (mtier, for example), then you can install that package from them, and then upgrade later to a newer / different version of the same package from someone else later. You can have as many package sources as you want just by adding them into the PKG_PATH environment variable. If you want to build a custom version of a package - in the event that you somehow need one - then you can do that. This is equivalent to modifying the port, which you would do if you were personally updating the port to a new version (before the maintainer did it for you), or adding a new variant, or patching the port in some way. The resulting custom package can generally substitute for the 'official' package, so long as you haven't somehow broken it. If the mainline port is then updated, you can upgrade to it without issue. If you don't want to upgrade a particular package, then just don't upgrade it - the system will not complain at you unless some other package eventually requires the newer version. > Apt has an "install from source" system Building from ports is literally building a package from source. The resulting package is the same as every other package, and will even be signed with your own package signing key (if you set that up). It can be cleanly removed, upgraded, etc., just like everything else. The OpenBSD packages system is pretty great, and I've used apt. I personally find the pkg_* tools easier to use and more transparent than apt-*/dpkg, but I am sure this just boils down to familiarity. YMMV.
rubyfan 12y ago
I had much experience with ports about 10 years ago building from source and even maintaining and creating a few. I can say the community around ports and specifically Marc Espie were great. I also always found ports and OpenBSD to be explainable, non-surprising and simple as opposed to much of what I saw with rpm and apt.
- nextos 12y ago
  Ports work pretty well and without much hassle. In contrast, rpm and apt are pretty complex. I've never felt I've understood them. If using Linux, I very much prefer pacman. However, all seem to be stuck in the past. I wonder why the ideas pioneered by http://www.gobolinux.org/ http://www.gobolinux.org/ are not more widely implemented, leaving nix aside.
  - rubyfan 12y ago
    I was always a fan of contained packages as well. Apple generally does a nice job with application packages.

76 points by fcambus 12y ago

Edit: I was wrong about OpenBSD ports on several counts, it seems. OpenBSD seems to have corrected several omissions in package management that I've seen in the past; some of these changes seem to have come recently, in version 5.5. I'm reading docs now to see which of these issues have been resolved. Lest anyone be misled into believing ports is comparable to yum or apt...it is not. With ports it is not only possible, but likely, that you will end up with upgrades to some software that can break other pieces of your system, because the dependencies often do not account for things, like compile flags, which can be changed by the user at install time. This leads to a very fragile system a couple years down the road, after a bunch of upgrades and new software installation has occurred. This isn't theoretical; I've seen it happen more often than not in my very limited use of the ports system...it is avoidable, but it is not obvious or well-documented how to avoid it, and adds not insignificant costs to maintaining your systems. With ports it is not possible to verify that the files installed by the port match what was originally installed. This can be useful for security purposes (i.e. has the ps command been tampered with?) or for troubleshooting purposes (i.e. did someone install a program from a source tarball over the original package, or did permissions/ownership change?). Edit: I was wrong on this one. pkg_check verifies package contents against checksums, which is comparable to rpm -V or debsums. With ports, it is not possible to reliably roll-back to a prior version in-place (i.e. without uninstalling everything, and then reinstalling it). 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). OpenBSD has many fine qualities and very smart people working on it, and I don't think it's the dumbest idea ever to use it. But, ports is simply not a sufficient answer to the package management problem. RPM/yum and dpkg/apt are not perfect, but they are vastly superior to ports in every dimension. FreeBSD now has pkgng which is very much a move in the right direction, and it would be definite progress for OpenBSD to adopt it. Note that providing binaries or not is not on my list of complaints about ports, above. Somehow, in every conversation about ports failings as a package manager, there will always be people talking about binaries, and how you can totally install binaries with ports and so there's no reason to not like ports. I find it annoyingly time-consuming to build everything from scratch, but it's not a deal-breaker. Providing binary packages is not why apt and yum are vastly superior to ports.

tech-no-logical 12y ago
I have little experience with compiling from ports myself (and that was mostly on freebsd), so I cannot really comment on that, but I've used the pkg_* system for years and have yet to run into serious problems like versioning-hell or pkg's breaking. dependencies are normally well resolved when (de)installing pkg's. even upgrading works pretty well for the most part. I agree that the package management could be better, but as far as I can tell it isn't as bad as you suggest as long as you stick to the official prebuilt packages. or is it different when following -current ? I usually stick to releases and only patch major bugs.
- derefr 12y ago
  This is like saying [some database] isn't as bad as you suggest as long as you aren't at the scale where you need distribution. The whole point of a package management system is how it handles the complex edge cases, not the simple linear accept-the-defaults cases. Apt, for example, knows how to consume variant packages from alternate sources and then upgrade back into mainline—but also allows the user to specify (with a "pin") that they prefer to continue on the alternative even if it's older. Apt also has an "install from source" system where the source package gets baked into a binary package within a chroot container on the installing system, and then that package gets installed. That package is then like any other package on the system, and can be cleanly removed, or upgraded from into a newer upstream release, etc. These are important features. They're not important for j-random-user, but they're important to distribution maintainers, and to sysops who have to, for example, apply temporary hotfixes to specific packages on their production machines until the distribution ships those same fixes, at which point they want to revert to upstream.
  - Mordak 12y ago
    It's kind of too bad that this thread started off the way it did, because there is now a bunch of misinformation in it. The OpenBSD ports system makes binary packages (and then installs them). Those binary packages are managed by the pkg_* tools, which allow users to install, verify, upgrade, delete, etc., packages. The binary packages are available on the mirrors if you don't want to compile them yourself. You just 'pkg_add <package>' and you're good to go. This is actually the recommended procedure, and users are discouraged from using ports unless they really need to. > Apt knows how to consume variant packages from alternate sources and then upgrade back into mainline... If someone else builds a package (mtier, for example), then you can install that package from them, and then upgrade later to a newer / different version of the same package from someone else later. You can have as many package sources as you want just by adding them into the PKG_PATH environment variable. If you want to build a custom version of a package - in the event that you somehow need one - then you can do that. This is equivalent to modifying the port, which you would do if you were personally updating the port to a new version (before the maintainer did it for you), or adding a new variant, or patching the port in some way. The resulting custom package can generally substitute for the 'official' package, so long as you haven't somehow broken it. If the mainline port is then updated, you can upgrade to it without issue. If you don't want to upgrade a particular package, then just don't upgrade it - the system will not complain at you unless some other package eventually requires the newer version. > Apt has an "install from source" system Building from ports is literally building a package from source. The resulting package is the same as every other package, and will even be signed with your own package signing key (if you set that up). It can be cleanly removed, upgraded, etc., just like everything else. The OpenBSD packages system is pretty great, and I've used apt. I personally find the pkg_* tools easier to use and more transparent than apt-*/dpkg, but I am sure this just boils down to familiarity. YMMV.

rubyfan 12y ago

I had much experience with ports about 10 years ago building from source and even maintaining and creating a few. I can say the community around ports and specifically Marc Espie were great. I also always found ports and OpenBSD to be explainable, non-surprising and simple as opposed to much of what I saw with rpm and apt.

nextos 12y ago
Ports work pretty well and without much hassle. In contrast, rpm and apt are pretty complex. I've never felt I've understood them. If using Linux, I very much prefer pacman. However, all seem to be stuck in the past. I wonder why the ideas pioneered by http://www.gobolinux.org/ http://www.gobolinux.org/ are not more widely implemented, leaving nix aside.
- rubyfan 12y ago
  I was always a fan of contained packages as well. Apple generally does a nice job with application packages.