6 ms·

> Its dependency resolution capabilities are awful Funny. I had more problems with APT dependency resolution than with ports dependency resolution, probably b

> Its dependency resolution capabilities are awful Funny. I had more problems with APT dependency resolution than with ports dependency resolution, probably by an order of magnitude, despite the fact that APT was the best package system I had encountered in Linux-land. > its third party repository capabilities non-existent I must admit that APT's third-party repository capabilities are pretty nice. On the other hand, I have not needed a third-party repository with FreeBSD yet, so I have no basis for comparison. > scripting it is an exercise in frustration Strange. I've scripted half a dozen different things for working with ports, because it was so easy to do, then subsequently found out that someone else had not only already done the same thing but done it better and committed it to ports. Your experience is obviously much different from mine. > packaging for ports is easy but leaves me with feelings of horrible guilt because of the complete and utter lack of regard for the sanity of the end user What's so insane about its (lack of) regard for the end user? Do you just think end users should never have to wait for a compile to finish? Is this an implied rehash of what you've already said? What exactly is the problem in this case? > uninstallation is laughably weak particularly with regard to dependencies Uninstallation appears about on par with APT from where I'm sitting. > the binary packages are universally unusable I don't bother using the binary packages, for the most part, but I know there are bunches of people who basically run their FreeBSD systems entirely off binary packages. I suspect they would disagree with your assessment. > you can't query ports for the actual state of the filesystem vs. what it thinks the state of the filesystem is because it simply doesn't know Example, or clearer explanation, please. > since ports doesn't support third party repositories in any reasonable fashion it doesn't matter, since you can't use the native package management on FreeBSD to distribute your applications anyway I find this difficult to believe, but what the hell -- I haven't bothered looking into it. I'll just accept what you say for argument's sake, for now. > Sorry for the angry rant, but my level of disgust at seeing ports held up as an example of something good about FreeBSD is impossible to contain. That's obvious. Too bad your disgust for it runs completely counter to my own experience.

SwellJoe 16y ago
"Funny. I had more problems with APT dependency resolution than with ports dependency resolution, probably by an order of magnitude, despite the fact that APT was the best package system I had encountered in Linux-land." With ports it is entirely possible to install a package that does not work completely or at all due to missing dependencies. This is not something you ever need to think about with apt-get or yum. But on FreeBSD, I found it to be true of three or four packages out of a dozen or so that our software depends on (Apache, in particular, is really easy to screw up if you want any reasonable feature set; the ProFTPd port was broken for years). If you'd like an example, try installing the Apache port with all the major features that you'd expect in a virtual hosting environment, without intentionally installing all the pre-requisites in advance. You'll find that you've got a steaming pile of wreckage at the end of your nice long wait for it to build. "Uninstallation appears about on par with APT from where I'm sitting." 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. "I don't bother using the binary packages, for the most part, but I know there are bunches of people who basically run their FreeBSD systems entirely off binary packages. I suspect they would disagree with your assessment." I simply can't believe anyone could run a fully functional, and secure, FreeBSD system on nothing but binary packages. Many of them simply do not work once you bring the system up to date. The libraries move out from under the binaries, and they simply stop functioning. Either they'd be running an out of date, and thus insecure, system, or they're having to rebuild packages along the way to keep things working (and 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 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? "> you can't query ports for the actual state of the filesystem vs. what it thinks the state of the filesystem is because it simply doesn't know Example, or clearer explanation, please." 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. ports provides very little means of finding out what's already running on the system, which, from the perspective of someone trying to automate installation of a huge array of packages, while avoiding breaking any existing packages that the user may have pre-installed with custom options, is a pretty horrible experience. "> since ports doesn't support third party repositories in any reasonable fashion it doesn't matter, since you can't use the native package management on FreeBSD to distribute your applications anyway I find this difficult to believe, but what the hell -- I haven't bothered looking into it. I'll just accept what you say for argument's sake, for now." 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). You could also fudge your port into the ports tree, but that's undocumented, and the FreeBSD developers I talked to said it was a bad idea, and besides it still doesn't solve the problem of keeping your packages up to date using native means. You'd have to write a script or something that the user would need to run in addition to the usual ports management stuff to keep downloading and munging in your ports. 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. Our products already have one (because it runs on hundreds of operating systems and versions, most of which don't have reasonable package management), but we strongly prefer to keep it native, since 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. "> Sorry for the angry rant, but my level of disgust at seeing ports held up as an example of something good about FreeBSD is impossible to contain. That's obvious. Too bad your disgust for it runs completely counter to my own experience." Give it time.
- apotheon 16y ago
  > 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

"Funny. I had more problems with APT dependency resolution than with ports dependency resolution, probably by an order of magnitude, despite the fact that APT was the best package system I had encountered in Linux-land." With ports it is entirely possible to install a package that does not work completely or at all due to missing dependencies. This is not something you ever need to think about with apt-get or yum. But on FreeBSD, I found it to be true of three or four packages out of a dozen or so that our software depends on (Apache, in particular, is really easy to screw up if you want any reasonable feature set; the ProFTPd port was broken for years). If you'd like an example, try installing the Apache port with all the major features that you'd expect in a virtual hosting environment, without intentionally installing all the pre-requisites in advance. You'll find that you've got a steaming pile of wreckage at the end of your nice long wait for it to build. "Uninstallation appears about on par with APT from where I'm sitting." 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. "I don't bother using the binary packages, for the most part, but I know there are bunches of people who basically run their FreeBSD systems entirely off binary packages. I suspect they would disagree with your assessment." I simply can't believe anyone could run a fully functional, and secure, FreeBSD system on nothing but binary packages. Many of them simply do not work once you bring the system up to date. The libraries move out from under the binaries, and they simply stop functioning. Either they'd be running an out of date, and thus insecure, system, or they're having to rebuild packages along the way to keep things working (and 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 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? "> you can't query ports for the actual state of the filesystem vs. what it thinks the state of the filesystem is because it simply doesn't know Example, or clearer explanation, please." 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. ports provides very little means of finding out what's already running on the system, which, from the perspective of someone trying to automate installation of a huge array of packages, while avoiding breaking any existing packages that the user may have pre-installed with custom options, is a pretty horrible experience. "> since ports doesn't support third party repositories in any reasonable fashion it doesn't matter, since you can't use the native package management on FreeBSD to distribute your applications anyway I find this difficult to believe, but what the hell -- I haven't bothered looking into it. I'll just accept what you say for argument's sake, for now." 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). You could also fudge your port into the ports tree, but that's undocumented, and the FreeBSD developers I talked to said it was a bad idea, and besides it still doesn't solve the problem of keeping your packages up to date using native means. You'd have to write a script or something that the user would need to run in addition to the usual ports management stuff to keep downloading and munging in your ports. 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. Our products already have one (because it runs on hundreds of operating systems and versions, most of which don't have reasonable package management), but we strongly prefer to keep it native, since 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. "> Sorry for the angry rant, but my level of disgust at seeing ports held up as an example of something good about FreeBSD is impossible to contain. That's obvious. Too bad your disgust for it runs completely counter to my own experience." Give it time.

apotheon 16y ago
> 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.