6 ms·

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 f

• derefr 11y 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 11y 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.
    • SwellJoe 11y ago
      "You can have as many package sources as you want just by adding them into the PKG_PATH environment variable." This is great! I didn't know this was possible, and it's been one of my biggest complaints about ports on FreeBSD (I don't know if FreeBSD supports something similar now, but it didn't as recently as a few years ago). Apologies for starting the thread off with some misinformation and seemingly incorrect negativity. I have had many, many, very bad experiences with ports, mostly on FreeBSD. I made some assumptions that OpenBSD ports was equivalent to FreeBSD ports. I also based my comments on out-dated information.
    • derefr 11y ago
      Admittedly, I just have a vague sysop-level knowledge of apt (I've made a few Ubuntu PPAs, etc.), and have also never used the BSD tooling. So thank you for correcting my misinformation. On the other hand, AFAIK, my "misinformation" is also the "common wisdom" in the Linux sphere on the subject. So I guess I have (unintentionally) used the "Linux can't do X" (or in this case, BSD can't do X) rhetorical trick to prod you into providing the hard facts that were needed in this conversation. I'm not sure whether I feel bad about doing that. I guess I could have couched my assertions about apt in "so this is what I believe"s. Basically, the reverse of a "this is what I hear you saying, am I understanding you correctly" statement—instead, something more of a "this is what 'my' side is taking as axiomatic assumptions, I think; I'll list mine, and you can list yours, and then we can have a discussion without implicit knowledge." Feels very much like http://lesswrong.com/lw/np/disputing_definitions/ http://lesswrong.com/lw/np/disputing_definitions/, when I put it that way.
  • tete 11y ago
    Sorry, I really don't want to talk badly about apt. I don't think it's a bad system, but all the examples you gave are things where people tend to run into horrible problems, things that wouldn't have happened if they used ports. I don't think I completely understand the second statement. Sounds like a system like poudriere and similar to me. Also you can do the same on per-port basis. I do that, for example when I want to install a package that got released a minute ago I simply update the like that has the package version with the new one and install it. This works out great. 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. Especially on edge cases ports and packages seem to work way better than yum/apt, cause the complexity and the number of things that break is lower. Also how packages work is easily comprehensible (something I always enjoyed about Arch Linux too). This isn't exactly true for .deb or .rpm. Hotfixes are another great example where ports are superior. As described above the formats in which ports are described are incredibly easy compared to how things work in the RPM/DEB world. We don't have many sysop people at our company, so time for that is precious. Using FreeBSD and its ports system actually reduced the overhead on package-related stuff a lot.