4 ms·

OpenBSD has both binary packages and ports. Actually, the packages are built from ports, so if you want to customize a package, you checkout the ports tree, adj

by marios 11y ago

OpenBSD has both binary packages and ports. Actually, the packages are built from ports, so if you want to customize a package, you checkout the ports tree, adjust the Makefile, add patches or whatever it is you need, and then you get a nice package that you can use on other OpenBSD installations (provided they are running the same version). This is similar to what one does with, say, APT (apt-get {build-dep, source} <pkg>; modify; dpkg-builpackage ...). When you get install a release, you set a package source (/etc/pkg.conf is more or less the equivalent of /etc/apt/*), and then you just pkg_add <pkg>. Package versions are fixed, pretty much the same way you get when you run debian stable. There is one major difference though: OpenBSD is an OS, while Debian is a distribution. This means that debian will install the package files relatively to /, while OpenBSD will install them relatively to /usr/local. It may sound stupid if you've only used Linux before, but it makes sense: files in /usr/bin, /usr/sbin,... are files that were shipped with the OS. What lives in /usr/local is what you installed on top of it. Other than that, I don't see any major difference. You occasionally get some libraries that are out of sync with a package, but that happens on -current and it's usually that the package was not rebuilt yet on the mirror you're using. (Ever run Debian sid ? Well, it's the same thing) What I'm saying is that OpenBSD uses ports effectively and in day to day usage I see no difference to APT-based distributions. I've never used it, but I hear very good things about pkgsrc (developed by NetBSD but it can also be used elsewhere. AFAIK, Joyent uses it and some people run it on Linux too). From what I can see on the homepage, it provides both sources and binaries. Until pkgng was introduced, FreeBSD was lagging behind but from what I can tell, it seems the situation has improved. What "weaknesses" related to ports do you have in mind ?

SwellJoe 11y ago
"What "weaknesses" related to ports do you have in mind ?" The ones I've mentioned (and mentioned in the article we're commenting on): - Library mismatches leading to broken packages, sometimes on a freshly installed system. I've always heard outright denial that this happens, but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. - Poor dependency resolution, and weak validation tools, that requires manual intervention to prevent or repair those breakages which are bound to occur. Other complaints I have about ports: - No reasonable mechanism for offering third party package repositories. - Default ports are usually anemic, missing very basic functionality, guaranteeing you have to build some things from source in order to get a really functional version of, say, Apache. Now, you have to make your own means of distributing these custom builds across your systems, without any reasonable means of setting up your own repository (you can duplicate the whole ports tree, and merge your changes, which is ridiculous, and the tools to help with this are weak). Really, the biggest failings are in dependency specification and resolution. I don't know if it is a process failure (e.g., nobody is taking the time to specify things precisely enough to end up with a working package in every circumstance) or failure of the system (e.g., the system doesn't provide the means to specify things precisely enough to insure a functional system), or a combination of the two. But, the end result is that it is frightfully easy to end up with broken software, and often requires a lot of knowledge and human interaction to fix it. Again, providing binaries is fine and all (and, I think, mandatory for large automated deployments), but is not the basis of the problems I've experienced with ports. The fragility of ports is my problem with it, not the surface level differences between how things are installed and updated.
- 2trill2spill 11y ago
  > but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. You must be doing something wrong if every FreeBSD install you do ends up broken. Also before updating software in FreeBSD it's nice to take a ZFS snapshot before hand so you can roll back if something goes wrong, i've never had to rollback personally but it's still a nice precaution. > - No reasonable mechanism for offering third party package repositories. What do you mean? you can change pkg repos's by changing the configuration file. [1] [1]: https://www.freebsd.org/cgi/man.cgi?query=pkg.conf&sektion=5&manpath=FreeBSD+10.2-RELEASE https://www.freebsd.org/cgi/man.cgi?query=pkg.conf&sektion=5...
  - SwellJoe 11y ago
    "What do you mean? you can change pkg repos's by changing the configuration file." That is new in FreeBSD 10, and did not apply to the versions I was working with. I assume it is part of pkgng?
- tw04 11y ago
  >- Library mismatches leading to broken packages, sometimes on a freshly installed system. I've always heard outright denial that this happens, but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. I'm not questioning that is your experience, but I am curious what packages specifically, and what specifically broke. Because in my almost 20 years of using FreeBSD, I have literally never once had that happen. Just generically saying "It always breaks" without examples is pretty difficult for anyone to defend or even begin to try to counter.
  - SwellJoe 11y ago
    Some that come to mind: On FreeBSD 8 (I think), installing Postfix alongside several other packages that relied on OpenSSL led to Postfix breaking, because the OpenSSL version was updated but Postfix was not. This happened regardless of binary or source install. I don't remember the specifics, honestly, as it's been a while. But, it required manual intervention and patching the port to make it rebuild a functioning Postfix. On some earlier FreeBSD version, I had a dependency hell situation arise with Apache. Again, some library got moved out from under it, and dependencies weren't sufficiently specific to allow it to be automatically fixed, even with a complete rebuild of all of the packages (which would be a ridiculous requirement that I would still complain about..but even that wouldn't work). On the same system, saslauthd was utterly broken for months (maybe even years), whether installed from binary or source (there was an issue about it, nothing happened). It required me to manually patch it and update it to make it work. Also, despite assertions to the contrary, I've found that "mixed" systems of binaries plus ports also often leads to brokenness (the port install will lead to a library being upgraded out from under the binary install software, requiring a port install from source to fix the problem). That should never happen. Random shit should never just stop working because you installed another package, and I've found it to happen at least once or twice on any FreeBSD system I've ever dealt with. All of this is fuzzy memories. It's been a few years since I earnestly tried to support FreeBSD in our products, because the package management situation was such an ugly mess. Before that some of the kernel limits were problematic (like group membership was limited to 128 or 256 groups, which broke our permissions model for Apache back then, so we had to rebuild the kernel just to make our software functional). There's just been a lot of pain involved in making FreeBSD work for us, and I've spent more fruitless hours trying to make it work than any other system we support (and for a much smaller pool of paying customers...we can count the FreeBSD users on our fingers, vs. a few thousand Linux users). Despite a very low return on investment, I still dig in every few years and waste hours of my time fighting with shitty package management, because I really want to support it. Anyway, let me be clear about this: If you have to manually patch or edit anything to get a functional installation, your package management tools are broken. In my experience, that's always been required. Admittedly, our stack of dependencies for our software is very large (Apache, MySQL, PostgreSQL, Postfix, Dovecot, Cyrus saslauthd, BIND, procmail, spamassassin, ClamAV, Perl and several modules, bash, awstats, modern Python and Ruby versions, and more that isn't coming to mind right now). Can I make it work? Yes, I've done it a handful of times in our ten years of making Virtualmin as a commercial product. I honestly want to support FreeBSD, and always have wanted to support FreeBSD. xBSD users are almost universally extremely competent; they file useful bug reports, they're helpful when I have problems based on the limits of my knowledge of FreeBSD. But, it's always a massive pain in the ass, and when a new version rolls out, I find I have another stack of problems to work out manually. Most of those problems are related to package management failures. Also, while xBSD users are often awesomely bright folks, they're also extremely defensive, to the point of it being difficult to address problems (like this one). We're talking about a post in the DragonflyBSD list that discusses this very problem, the exact thing I'm belly aching about, is a thing that is acknowledged as a longstanding issue in ports by the developers who have made some changes to try to address the problem. Why are we arguing about whether it happens? (I understand DragonflyBSD and FreeBSD have diverged many years ago, and there are significant differences, including in package management, but this seems to be a problem of ports in general, in my experience.)

by marios 11y ago

SwellJoe 11y ago

"What "weaknesses" related to ports do you have in mind ?" The ones I've mentioned (and mentioned in the article we're commenting on): - Library mismatches leading to broken packages, sometimes on a freshly installed system. I've always heard outright denial that this happens, but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. - Poor dependency resolution, and weak validation tools, that requires manual intervention to prevent or repair those breakages which are bound to occur. Other complaints I have about ports: - No reasonable mechanism for offering third party package repositories. - Default ports are usually anemic, missing very basic functionality, guaranteeing you have to build some things from source in order to get a really functional version of, say, Apache. Now, you have to make your own means of distributing these custom builds across your systems, without any reasonable means of setting up your own repository (you can duplicate the whole ports tree, and merge your changes, which is ridiculous, and the tools to help with this are weak). Really, the biggest failings are in dependency specification and resolution. I don't know if it is a process failure (e.g., nobody is taking the time to specify things precisely enough to end up with a working package in every circumstance) or failure of the system (e.g., the system doesn't provide the means to specify things precisely enough to insure a functional system), or a combination of the two. But, the end result is that it is frightfully easy to end up with broken software, and often requires a lot of knowledge and human interaction to fix it. Again, providing binaries is fine and all (and, I think, mandatory for large automated deployments), but is not the basis of the problems I've experienced with ports. The fragility of ports is my problem with it, not the surface level differences between how things are installed and updated.

2trill2spill 11y ago
> but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. You must be doing something wrong if every FreeBSD install you do ends up broken. Also before updating software in FreeBSD it's nice to take a ZFS snapshot before hand so you can roll back if something goes wrong, i've never had to rollback personally but it's still a nice precaution. > - No reasonable mechanism for offering third party package repositories. What do you mean? you can change pkg repos's by changing the configuration file. [1] [1]: https://www.freebsd.org/cgi/man.cgi?query=pkg.conf&sektion=5&manpath=FreeBSD+10.2-RELEASE https://www.freebsd.org/cgi/man.cgi?query=pkg.conf&sektion=5...
- SwellJoe 11y ago
  "What do you mean? you can change pkg repos's by changing the configuration file." That is new in FreeBSD 10, and did not apply to the versions I was working with. I assume it is part of pkgng?
tw04 11y ago
>- Library mismatches leading to broken packages, sometimes on a freshly installed system. I've always heard outright denial that this happens, but I've literally never installed a FreeBSD system that didn't end up with something broken by the time everything needed for a fully functioning web hosting system was installed. It's like there's Stockholm syndrome happening, or something. I'm not questioning that is your experience, but I am curious what packages specifically, and what specifically broke. Because in my almost 20 years of using FreeBSD, I have literally never once had that happen. Just generically saying "It always breaks" without examples is pretty difficult for anyone to defend or even begin to try to counter.
- SwellJoe 11y ago
  Some that come to mind: On FreeBSD 8 (I think), installing Postfix alongside several other packages that relied on OpenSSL led to Postfix breaking, because the OpenSSL version was updated but Postfix was not. This happened regardless of binary or source install. I don't remember the specifics, honestly, as it's been a while. But, it required manual intervention and patching the port to make it rebuild a functioning Postfix. On some earlier FreeBSD version, I had a dependency hell situation arise with Apache. Again, some library got moved out from under it, and dependencies weren't sufficiently specific to allow it to be automatically fixed, even with a complete rebuild of all of the packages (which would be a ridiculous requirement that I would still complain about..but even that wouldn't work). On the same system, saslauthd was utterly broken for months (maybe even years), whether installed from binary or source (there was an issue about it, nothing happened). It required me to manually patch it and update it to make it work. Also, despite assertions to the contrary, I've found that "mixed" systems of binaries plus ports also often leads to brokenness (the port install will lead to a library being upgraded out from under the binary install software, requiring a port install from source to fix the problem). That should never happen. Random shit should never just stop working because you installed another package, and I've found it to happen at least once or twice on any FreeBSD system I've ever dealt with. All of this is fuzzy memories. It's been a few years since I earnestly tried to support FreeBSD in our products, because the package management situation was such an ugly mess. Before that some of the kernel limits were problematic (like group membership was limited to 128 or 256 groups, which broke our permissions model for Apache back then, so we had to rebuild the kernel just to make our software functional). There's just been a lot of pain involved in making FreeBSD work for us, and I've spent more fruitless hours trying to make it work than any other system we support (and for a much smaller pool of paying customers...we can count the FreeBSD users on our fingers, vs. a few thousand Linux users). Despite a very low return on investment, I still dig in every few years and waste hours of my time fighting with shitty package management, because I really want to support it. Anyway, let me be clear about this: If you have to manually patch or edit anything to get a functional installation, your package management tools are broken. In my experience, that's always been required. Admittedly, our stack of dependencies for our software is very large (Apache, MySQL, PostgreSQL, Postfix, Dovecot, Cyrus saslauthd, BIND, procmail, spamassassin, ClamAV, Perl and several modules, bash, awstats, modern Python and Ruby versions, and more that isn't coming to mind right now). Can I make it work? Yes, I've done it a handful of times in our ten years of making Virtualmin as a commercial product. I honestly want to support FreeBSD, and always have wanted to support FreeBSD. xBSD users are almost universally extremely competent; they file useful bug reports, they're helpful when I have problems based on the limits of my knowledge of FreeBSD. But, it's always a massive pain in the ass, and when a new version rolls out, I find I have another stack of problems to work out manually. Most of those problems are related to package management failures. Also, while xBSD users are often awesomely bright folks, they're also extremely defensive, to the point of it being difficult to address problems (like this one). We're talking about a post in the DragonflyBSD list that discusses this very problem, the exact thing I'm belly aching about, is a thing that is acknowledged as a longstanding issue in ports by the developers who have made some changes to try to address the problem. Why are we arguing about whether it happens? (I understand DragonflyBSD and FreeBSD have diverged many years ago, and there are significant differences, including in package management, but this seems to be a problem of ports in general, in my experience.)