4 ms·

> With ports it is entirely possible to install a package that does not work completely or at all due to missing dependencies. Meanwhile, I have discovered tha

> With ports it is entirely possible to install a package that does not work completely or at all due to missing dependencies. Meanwhile, I have discovered that with APT it is entirely possible for a failed install to hose up the entire package management system so that only "manually" fixing some broken dependency handling will allow me to use it again. > It's trivially easy to remove a package required by other packages with ports. Meaning that it's entirely possible to break vast swaths of your system without warning. Well, sure -- if you're a masochist. The same is true of Debian and Fedora, too, if you bypass the user-level tools and use the underlying utilities. If you use the user-level tools on FreeBSD, you get protections against doing that sort of thing, though. Let me guess: you always use "make deinstall" instead of pkg_deinstall. Right? > I simply can't believe anyone could run a fully functional, and secure, FreeBSD system on nothing but binary packages. I can't help what you are unwilling to believe. > The libraries move out from under the binaries, and they simply stop functioning. Are you installing libraries from ports and stuff that depends on the libraries from packages? I guess you could run into that problem under those circumstances. > Either they'd be running an out of date, and thus insecure, system You don't always have to update to run secure software. You only have to update when there are security updates. > they'd have to test to know which stuff is broken, because ports and the pkg tools won't warn you when you're breaking stuff by updating software I wouldn't know, because I haven't broken "stuff" by updating software the way you describe it. I have, however, had portupgrade warn me that if I installed something that required a different library version than another tool it would break something. Hmm. I guess I do know, and you're wrong, in my experience. > I also don't understand the mindset of anyone that chooses to wait hours for their system to be useful while they wait for a huge stack of ports to build. How little is your time worth to you? I don't wait hours for my system to be useful while waiting for a huge stack of ports to build. I build stuff while I use the system. Y'know, I had the same question before I started using FreeBSD regularly, then discovered that it's not really an issue. Go figure. > rpm -V httpd > > This command verifies the installation of httpd. Does what's running on the system match what the package contains? If not, it tells you which files have changed. > > There is no equivalent for ports that I know of, and I'm pretty sure it would be deeply non-trivial to implement such a command because I don't think ports have a manifest or any sort of particular knowledge about what the payload of the package is. You must not be familiar with pkg_info, or the pkg-plist file that is part of every port for that matter. There's actually probably a few dozen ways to achieve the same thing, including using mtree to verify filesystem integrity. Come to think of it, maybe you just aren't familiar with the ports system. > Yeah, I find it difficult to believe, too. It's just stupid, but it's true. You can build a pkg and install it, but then there's no way to keep it up to date via native means (except requiring the user to download and install new pkgs over time, which is unacceptable when there are dozens of packages to deal with). Yeah, yeah . . . like I said, I've never had to look into the use of third-party repositories, so I wouldn't know. I'm beginning to rethink taking your word for it, though, given your demonstrated lack of knowledge of basic ports management tools. In fact, a cursory look at the manpages for some ports management tools suggests that the ability to specify alternate sources for ports and/or packages is provided by these tools. I might look into this more. > So, if you want to distribute a pile of applications and keep them up to date, you have to build your own update management system. Even if the foregoing was true, this would not be true. There are gobs of cross-platform options available for software management, including even repurposed version control systems. You do not need to design your own software management system from scratch. > people already understand how to keep their system up to date using yum or apt-get, or whatever. We don't have that ability on FreeBSD. Have you tried submitting to ports? > Give it time. How much time does it take? I have been using FreeBSD for years already.

SwellJoe 16y ago
Obviously our experiences have been different. I'll readily admit that I'm not an expert with ports or apt-get (I've been a Red Hat, Fedora, CentOS user for about 15 years, so I'm deeply familiar with RPM, and know exactly what to expect there), and my entire experience with both has been building our installation script and updates management stuff for both platforms. apt-get mostly just worked for everything I needed it to do. Yes, it has some occasional quirks, specifically when running it via scripts--there are some actions which are pretty much impossible to script. apt-get, for instance, won't replace a package with a different version to satisfy a dependency when run non-interactively, even if the package being replaced is not required by any other packages on the system. So, if you want to replace a package, you have to explicitly remove it first, and then install the replacement. This is weird, but it's not disastrous. I don't consider apt-get as reliable as yum/RPM for a number of reasons that I've discovered along the way, but it's miles above ports/pkg. FreeBSD ports and pkg tools, on the other hand, have some really scary quirks. For example, installing a pkg non-interactively may fail, but return success. Or, it may return failure, but the package actually installed successfully. There had been a bug about it in the FreeBSD tracker about it for a couple of years when I ran into it...I don't know if it's been fixed by now. This was during the 7.0 release cycle. So, our installation verification stuff doesn't work on FreeBSD; we have to just say, "Installation probably completed OK, but we don't know for sure because the pkg tools don't always return accurate information about installation success or failure." I've already mentioned the dependency issues I've run into. I can't believe I'm a unique and special flower in this regard, but maybe the dozen package we deal with and the exact options we need are uniquely broken when installing in a non-interactive fashion, and nobody else runs into them, ever. I certainly did. This aspect of supporting FreeBSD alone took a couple of weeks to work out, and the solution has never been to my satisfaction. So, I'm happy to admit that my knowledge of ports is pretty miserable. But, the same can be said of my knowledge of apt-get...and the amount of effort that went into getting our installation script working on Debian vs. FreeBSD was dramatically different. And, the resulting reliability on Debian is dramatically higher than on FreeBSD. And, at the end of it all, the user can run "apt-get update; apt-get upgrade" and our packages get updated along with everything else. And, we have a nice UI in the product itself that can query the native package manager to display a list of available updates and such. All nicely integrated and comfortable for people who are already familiar with their OS. No such luck on FreeBSD. It's all different pieces that don't really fit comfortably together. Some are binary pkgs (because the install would take hours otherwise), some are ports, and some are from our own package format. "> Either they'd be running an out of date, and thus insecure, system You don't always have to update to run secure software. You only have to update when there are security updates." So as long as no security updates happen, we're golden! "> rpm -V httpd > > This command verifies the installation of httpd. Does what's running on the system match what the package contains? If not, it tells you which files have changed. > > There is no equivalent for ports that I know of, and I'm pretty sure it would be deeply non-trivial to implement such a command because I don't think ports have a manifest or any sort of particular knowledge about what the payload of the package is. You must not be familiar with pkg_info, or the pkg-plist file that is part of every port for that matter. There's actually probably a few dozen ways to achieve the same thing, including using mtree to verify filesystem integrity." I found pkg_info during my Trail of FreeBSD Tears, but I don't believe it tells you about the configuration of the installed port, does it? I don't remember exactly what information I needed and couldn't get, as it's been a couple of years since I was banging on it seriously, but I do recall there were details I couldn't get making it difficult to figure out the actual state of the system. But, it's good to know that you can actually verify your packages and their contents. I'm not sure I believe it works as documented, since so few aspects of ports and pkg tools actually do in my experience, but in the absence of evidence to the contrary, let's just say it does. Point conceded. "> Yeah, I find it difficult to believe, too. It's just stupid, but it's true. You can build a pkg and install it, but then there's no way to keep it up to date via native means (except requiring the user to download and install new pkgs over time, which is unacceptable when there are dozens of packages to deal with). Yeah, yeah . . . like I said, I've never had to look into the use of third-party repositories, so I wouldn't know. I'm beginning to rethink taking your word for it, though, given your demonstrated lack of knowledge of basic ports management tools. In fact, a cursory look at the manpages for some ports management tools suggests that the ability to specify alternate sources for ports and/or packages is provided by these tools. I might look into this more." If you figure it out, please let me know. I hate our current distribution and installation process on FreeBSD, and having the ability to use native packages with native update mechanisms would be great. I spoke to Colin Percival (created freebsd-update, and long-time FreeBSD developer) about it in the past, and he had no suggestions, beyond the already mentioned options. "> people already understand how to keep their system up to date using yum or apt-get, or whatever. We don't have that ability on FreeBSD. Have you tried submitting to ports?" Some of the packages are commercial software, and the code is behind user:pass authentication on our servers. We also have to override the Apache and ProFTPd ports, because we need custom options (actually we're just building the port after modifying the configure options), though I believe ports handles this correctly and keeps our chosen build options through upgrades...I hope so, anyway, and I don't think we've gotten any tickets about it, so I guess it does, though our FreeBSD user base is pretty small (a few hundred vs. hundreds of thousands of CentOS installs). It's a pretty non-trivial endeavor. I believe Webmin and Virtualmin GPL, and some of the Virtualmin modules, already have ports. Which is cool, but we do need direct control over things for the commercial software. "> So, if you want to distribute a pile of applications and keep them up to date, you have to build your own update management system. Even if the foregoing was true, this would not be true. There are gobs of cross-platform options available for software management, including even repurposed version control systems. You do not need to design your own software management system from scratch." As I mentioned, we've had our own cross-platform package manager built into our software for years. But, it's not native. That's the source of my complaint. I would like for users who are already familiar with the native means of keeping their system up to date can keep our software up to date, as well. I don't want more confusing update options for users to have to figure out. I want less. I want One True Package Manager on the system and I want it to be able to manage and update all the packages. Adding more software to an already large stack is exactly the opposite of what I want to do. yum/rpm makes this trivially easy. apt-get makes it reasonably easy. FreeBSD makes it pretty much impossible as far as I can tell. But, hey, if you get it figured out, I'd be more than happy to be wrong. Supporting FreeBSD has been a pain in my ass for years now, and it'll continue to be so as long as installation is such a mess. The tragedy of all this is that I really like FreeBSD. I think it's a fine OS with good docs and a really smart bunch of users (our FreeBSD users tend to be better educated about their systems than our CentOS users, on average; which makes sense, given that CentOS is the "standard" in hosting, and you'd have to go seek out FreeBSD). But, I just have had so much unbelievable pain and confusion and wasted time because of ports that it's rage-inducing.

SwellJoe 16y ago

Obviously our experiences have been different. I'll readily admit that I'm not an expert with ports or apt-get (I've been a Red Hat, Fedora, CentOS user for about 15 years, so I'm deeply familiar with RPM, and know exactly what to expect there), and my entire experience with both has been building our installation script and updates management stuff for both platforms. apt-get mostly just worked for everything I needed it to do. Yes, it has some occasional quirks, specifically when running it via scripts--there are some actions which are pretty much impossible to script. apt-get, for instance, won't replace a package with a different version to satisfy a dependency when run non-interactively, even if the package being replaced is not required by any other packages on the system. So, if you want to replace a package, you have to explicitly remove it first, and then install the replacement. This is weird, but it's not disastrous. I don't consider apt-get as reliable as yum/RPM for a number of reasons that I've discovered along the way, but it's miles above ports/pkg. FreeBSD ports and pkg tools, on the other hand, have some really scary quirks. For example, installing a pkg non-interactively may fail, but return success. Or, it may return failure, but the package actually installed successfully. There had been a bug about it in the FreeBSD tracker about it for a couple of years when I ran into it...I don't know if it's been fixed by now. This was during the 7.0 release cycle. So, our installation verification stuff doesn't work on FreeBSD; we have to just say, "Installation probably completed OK, but we don't know for sure because the pkg tools don't always return accurate information about installation success or failure." I've already mentioned the dependency issues I've run into. I can't believe I'm a unique and special flower in this regard, but maybe the dozen package we deal with and the exact options we need are uniquely broken when installing in a non-interactive fashion, and nobody else runs into them, ever. I certainly did. This aspect of supporting FreeBSD alone took a couple of weeks to work out, and the solution has never been to my satisfaction. So, I'm happy to admit that my knowledge of ports is pretty miserable. But, the same can be said of my knowledge of apt-get...and the amount of effort that went into getting our installation script working on Debian vs. FreeBSD was dramatically different. And, the resulting reliability on Debian is dramatically higher than on FreeBSD. And, at the end of it all, the user can run "apt-get update; apt-get upgrade" and our packages get updated along with everything else. And, we have a nice UI in the product itself that can query the native package manager to display a list of available updates and such. All nicely integrated and comfortable for people who are already familiar with their OS. No such luck on FreeBSD. It's all different pieces that don't really fit comfortably together. Some are binary pkgs (because the install would take hours otherwise), some are ports, and some are from our own package format. "> Either they'd be running an out of date, and thus insecure, system You don't always have to update to run secure software. You only have to update when there are security updates." So as long as no security updates happen, we're golden! "> rpm -V httpd > > This command verifies the installation of httpd. Does what's running on the system match what the package contains? If not, it tells you which files have changed. > > There is no equivalent for ports that I know of, and I'm pretty sure it would be deeply non-trivial to implement such a command because I don't think ports have a manifest or any sort of particular knowledge about what the payload of the package is. You must not be familiar with pkg_info, or the pkg-plist file that is part of every port for that matter. There's actually probably a few dozen ways to achieve the same thing, including using mtree to verify filesystem integrity." I found pkg_info during my Trail of FreeBSD Tears, but I don't believe it tells you about the configuration of the installed port, does it? I don't remember exactly what information I needed and couldn't get, as it's been a couple of years since I was banging on it seriously, but I do recall there were details I couldn't get making it difficult to figure out the actual state of the system. But, it's good to know that you can actually verify your packages and their contents. I'm not sure I believe it works as documented, since so few aspects of ports and pkg tools actually do in my experience, but in the absence of evidence to the contrary, let's just say it does. Point conceded. "> Yeah, I find it difficult to believe, too. It's just stupid, but it's true. You can build a pkg and install it, but then there's no way to keep it up to date via native means (except requiring the user to download and install new pkgs over time, which is unacceptable when there are dozens of packages to deal with). Yeah, yeah . . . like I said, I've never had to look into the use of third-party repositories, so I wouldn't know. I'm beginning to rethink taking your word for it, though, given your demonstrated lack of knowledge of basic ports management tools. In fact, a cursory look at the manpages for some ports management tools suggests that the ability to specify alternate sources for ports and/or packages is provided by these tools. I might look into this more." If you figure it out, please let me know. I hate our current distribution and installation process on FreeBSD, and having the ability to use native packages with native update mechanisms would be great. I spoke to Colin Percival (created freebsd-update, and long-time FreeBSD developer) about it in the past, and he had no suggestions, beyond the already mentioned options. "> people already understand how to keep their system up to date using yum or apt-get, or whatever. We don't have that ability on FreeBSD. Have you tried submitting to ports?" Some of the packages are commercial software, and the code is behind user:pass authentication on our servers. We also have to override the Apache and ProFTPd ports, because we need custom options (actually we're just building the port after modifying the configure options), though I believe ports handles this correctly and keeps our chosen build options through upgrades...I hope so, anyway, and I don't think we've gotten any tickets about it, so I guess it does, though our FreeBSD user base is pretty small (a few hundred vs. hundreds of thousands of CentOS installs). It's a pretty non-trivial endeavor. I believe Webmin and Virtualmin GPL, and some of the Virtualmin modules, already have ports. Which is cool, but we do need direct control over things for the commercial software. "> So, if you want to distribute a pile of applications and keep them up to date, you have to build your own update management system. Even if the foregoing was true, this would not be true. There are gobs of cross-platform options available for software management, including even repurposed version control systems. You do not need to design your own software management system from scratch." As I mentioned, we've had our own cross-platform package manager built into our software for years. But, it's not native. That's the source of my complaint. I would like for users who are already familiar with the native means of keeping their system up to date can keep our software up to date, as well. I don't want more confusing update options for users to have to figure out. I want less. I want One True Package Manager on the system and I want it to be able to manage and update all the packages. Adding more software to an already large stack is exactly the opposite of what I want to do. yum/rpm makes this trivially easy. apt-get makes it reasonably easy. FreeBSD makes it pretty much impossible as far as I can tell. But, hey, if you get it figured out, I'd be more than happy to be wrong. Supporting FreeBSD has been a pain in my ass for years now, and it'll continue to be so as long as installation is such a mess. The tragedy of all this is that I really like FreeBSD. I think it's a fine OS with good docs and a really smart bunch of users (our FreeBSD users tend to be better educated about their systems than our CentOS users, on average; which makes sense, given that CentOS is the "standard" in hosting, and you'd have to go seek out FreeBSD). But, I just have had so much unbelievable pain and confusion and wasted time because of ports that it's rage-inducing.