5 ms·

Interesting! What is the advantage of the FreeBSD package manager over existing OS X package managers like Homebrew or MacPorts?

oellegaard 12y ago
It's a binary package manager vs homebrew that downloads the source, patches it and compiles it AFAIK.
- bitroliest 12y ago
  Homebrew can "bottle" binary packages and "pour" them on install also. https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Bottles.md https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
- mikepurvis 12y ago
  Most of the standard stuff in homebrew is available in bottled form. Which isn't to say Homebrew doesn't have its problems— setting up your own bottling infrastructure is difficult/impossible, and basic stuff like caching dependencies isn't there (cf. https://github.com/Homebrew/homebrew/issues/27457 https://github.com/Homebrew/homebrew/issues/27457).
  - skuhn 12y ago
    It can be done (I'm doing it in production), but it is not thought out with this situation in mind. I forked the formula repo at some point in the distant past, and untar it onto each machine. Then I manually manage dependencies when I tell it to fetch bottles from my own source. A lot of the simplicity and 'it just works' nature of Homebrew is because it's meant to be used in one situation and that's it.
    - mikemcquaid 12y ago
      You probably want to be using your own tap and the `root_url` in `bottle do` blocks. I'm open to improving your use-case if you can file a feature request about what you're trying to do. Thanks!
      - skuhn 12y ago
        Thanks for the reply. My main beef is that I don't terribly want to modify each standard formula (causing more work when I do sync with upstream), but I want the system to be completely self-contained. Most package managers separate these concerns. There's the package build stuff (debian dir, spec files, etc.), there's the package install stuff (living inside the packages), and there's the repo stuff (apt, yum). Homebrew's inclusion of the install / dep portion inside the formula rather than inside the built bottle make it kind of impossible to fit into the method that I'm accustomed to. Not really sure that such a fundamental change is worthwhile for you to implement, since 99% of your users probably don't want to install their own bottles from a local repo and not connect to the Internet for anything.
        mikemcquaid 12y ago
        If you create a tap rather than using a fork then this problem goes away as you'll never need to sync with upstream and can provide `root_url`s in your tap so your users can download things from e.g. local URLs.
  - mikemcquaid 12y ago
    For a long time bottling was just done by me on my local VMs. It's pretty simple really; `brew install --build-bottle wget && brew bottle --root-url youweb.com wget`, upload the outputted bottles somewhere and add the `bottle do` block into the formula file. You can go a step further with this by using the `brew test-bot.rb` script (https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/cmd/test-bot.rb https://github.com/Homebrew/homebrew/blob/master/Library/Hom...) that we use for our CI. With that it's `brew test-bot --ci-testing wget && brew test-bot --ci-upload wget` which will write to the formula file, commit and push it. Obviously there's a lot there that's hardcoded to our use-case but if you can create a feature request issue I'd be happy to work on better docs and more flexibility around this. Hope that's useful!
    - mikepurvis 12y ago
      That's fair, thanks for the response! The use case I'm interested in would be running the test-bot automatically in a Jenkins/buildbot/whatever environment, where you point the bot at a repo of Formulae and it dumps bottles to a storage provider like S3. Once the dependency caching issue is resolved, I'm interested in getting this to a point of anyone being able to relatively trivially deploy it. The other use case would be commercial entities wanting to distribute closed-source libraries or other software via bottle-only. So they'd want to run something as CI that would watch the private repo for a tag, and once tags are created, would automatically bottle those releases and push them out.
      - mikemcquaid 12y ago
        I'm not sure what the dependency caching issue has to do with bottling? The latter use-case I don't have any particular interest in writing code for myself but I'd consider merging PRs for. The prior is possible with brew-test-bot if you do the uploading yourself (although I may be adding S3 support in the coming months). Using Jenkins should make all of this pretty trivial as-is.
        mikepurvis 12y ago
        The dependency caching is orthogonal to bottling; it's just that there's little incentive for me or anyone else to set up or document the bottling process (for ROS on OS X) until the created bottles are usable, which is not presently the case.
  - mikemcquaid 12y ago
    It's also worth noting that what you've mentioned about "caching dependencies" isn't caching them on disk (we do that already and extensively) but instead being able to cache it in memory to make dependency resolution faster. I don't think that's basic stuff and most users don't seem to have a problem with the speed of such things.
    - mikepurvis 12y ago
      The current arrangement works great for relatively shallow dependency trees; since that's what most homebrew packages have, it's not a big deal. Having this support in freebsd/pkg may make it a better choice for distributing software on OS X with dependency resolution needs more along the lines of what apt and yum are able to provide.
- Argorak 12y ago
  Both brew and macports provide that nowadays. I still see an advantage in using a package manager that is used for a full distro, allowing for easier management of packages. I am aware that this benefit might never materialize, but it's good some people try.
ics 12y ago
This might not answer your question completely, but here's a thread from the last time I recall this discussion happening: https://news.ycombinator.com/item?id=8402542 https://news.ycombinator.com/item?id=8402542 It's been a while since I used MacPorts, but I imagine there is some benefit to using the same packaging system between OSs and not having all package descriptions as executable ruby scripts.
emaste 12y ago
This change was written by Landon Fuller, one of the founders of MacPorts. There's an explanation for it in a comment on the pull request: https://github.com/freebsd/pkg/pull/1113#issuecomment-68063964 https://github.com/freebsd/pkg/pull/1113#issuecomment-680639... This change doesn't mean very much in isolation, but will hopefully be the beginning of some interesting collaboration by packagers on both platforms.
tootie 12y ago
It's good to combine efforts. It means potentially a bigger selection of packages that are available to install and more developers maintaining the project since it now has a wider potential user base.
tomphoolery 12y ago
IMHO, Homebrew offers a lot of advantages over traditional package management tools. It's simple to use, offers a really easy way to add your own packages, and contributing upstream is quite painless. MacPorts has always been reminiscent (to me, anyways) of the FreeBSD Ports Collection...it might even be based on it I'm not sure. So this seems like a prelude to a possible sunsetting of the MacPorts project in favor of simply using FreeBSD's package management tools on OS X. Not sure it's going to draw me away from using Homebrew just yet, but it's nice to know that there's a continuing effort to have OS X be a part of the UNIX-like OS community. (fake edit: it's been a LONG time since I've used FreeBSD. feel free to chime in about how wrong I am regarding the ease of adding ports on your own private or public server if things have changed)
- JonathonW 12y ago
  I don't think MacPorts is a direct derivative of the FreeBSD Ports Collection (someone can correct me if I'm wrong), but it's definitely inspired by FreeBSD Ports-- one of the original MacPorts coauthors (Jordan Hubbard) was the original developer of FreeBSD Ports. I won't be switching anytime soon, though. I moved to Homebrew a long time ago and haven't looked back-- MacPorts feels opaque and isolated in comparison.
  - yborg 12y ago
    >MacPorts feels opaque and isolated in comparison What does this even mean? If it means "uncool" then, yeah, I get it. If you are comfortable with Ruby, then it is easier to build packages for Homebrew, and since it isn't centrally managed like MacPorts, things generally get packaged quicker for Homebrew. On the other hand, MacPorts has a long track record and has generally been bombproof for me across 3 or 4 OS updates now. As an existing MacPorts user, I looked at it from the standpoint of "what is this doing for me that MacPorts doesn't?" I didn't see anything that seemed compelling enough to switch.
    - Camillo 12y ago
      I switched to Homebrew a long time ago, when MacPorts had a large advantage in number of packages, freshness, stability etc. For me, MacPorts' main mistake was to go all in with the "storage is cheap, CPU is cheap" canard just as everyone was abandoning desktops for laptops. MacPorts decided to build its own copy of almost everything that the OS distribution provides, to avoid having to deal with version differences between OS X releases. That might have been a decent tradeoff on a Mac Pro, but when you have a laptop with a small HD (and, later, an even smaller SSD), it is a real issue to have to permanently waste several GB on duplicate copies of Perl, Python etc. just because you want to build the GIMP; to say nothing of the hours it would take to build them. Homebrew's big selling point, for me, was that it could just use the libraries that already came with OS X.
mkhpalm 12y ago
Mainly just another sign for Apple that says: "Welcome to the 21st century! In this *nix era we have package managers!"

oellegaard 12y ago

It's a binary package manager vs homebrew that downloads the source, patches it and compiles it AFAIK.

bitroliest 12y ago
Homebrew can "bottle" binary packages and "pour" them on install also. https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Bottles.md https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
mikepurvis 12y ago
Most of the standard stuff in homebrew is available in bottled form. Which isn't to say Homebrew doesn't have its problems— setting up your own bottling infrastructure is difficult/impossible, and basic stuff like caching dependencies isn't there (cf. https://github.com/Homebrew/homebrew/issues/27457 https://github.com/Homebrew/homebrew/issues/27457).
- skuhn 12y ago
  It can be done (I'm doing it in production), but it is not thought out with this situation in mind. I forked the formula repo at some point in the distant past, and untar it onto each machine. Then I manually manage dependencies when I tell it to fetch bottles from my own source. A lot of the simplicity and 'it just works' nature of Homebrew is because it's meant to be used in one situation and that's it.
  - mikemcquaid 12y ago
    You probably want to be using your own tap and the `root_url` in `bottle do` blocks. I'm open to improving your use-case if you can file a feature request about what you're trying to do. Thanks!
    - skuhn 12y ago
      Thanks for the reply. My main beef is that I don't terribly want to modify each standard formula (causing more work when I do sync with upstream), but I want the system to be completely self-contained. Most package managers separate these concerns. There's the package build stuff (debian dir, spec files, etc.), there's the package install stuff (living inside the packages), and there's the repo stuff (apt, yum). Homebrew's inclusion of the install / dep portion inside the formula rather than inside the built bottle make it kind of impossible to fit into the method that I'm accustomed to. Not really sure that such a fundamental change is worthwhile for you to implement, since 99% of your users probably don't want to install their own bottles from a local repo and not connect to the Internet for anything.
      - mikemcquaid 12y ago
        If you create a tap rather than using a fork then this problem goes away as you'll never need to sync with upstream and can provide `root_url`s in your tap so your users can download things from e.g. local URLs.
- mikemcquaid 12y ago
  For a long time bottling was just done by me on my local VMs. It's pretty simple really; `brew install --build-bottle wget && brew bottle --root-url youweb.com wget`, upload the outputted bottles somewhere and add the `bottle do` block into the formula file. You can go a step further with this by using the `brew test-bot.rb` script (https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/cmd/test-bot.rb https://github.com/Homebrew/homebrew/blob/master/Library/Hom...) that we use for our CI. With that it's `brew test-bot --ci-testing wget && brew test-bot --ci-upload wget` which will write to the formula file, commit and push it. Obviously there's a lot there that's hardcoded to our use-case but if you can create a feature request issue I'd be happy to work on better docs and more flexibility around this. Hope that's useful!
  - mikepurvis 12y ago
    That's fair, thanks for the response! The use case I'm interested in would be running the test-bot automatically in a Jenkins/buildbot/whatever environment, where you point the bot at a repo of Formulae and it dumps bottles to a storage provider like S3. Once the dependency caching issue is resolved, I'm interested in getting this to a point of anyone being able to relatively trivially deploy it. The other use case would be commercial entities wanting to distribute closed-source libraries or other software via bottle-only. So they'd want to run something as CI that would watch the private repo for a tag, and once tags are created, would automatically bottle those releases and push them out.
    - mikemcquaid 12y ago
      I'm not sure what the dependency caching issue has to do with bottling? The latter use-case I don't have any particular interest in writing code for myself but I'd consider merging PRs for. The prior is possible with brew-test-bot if you do the uploading yourself (although I may be adding S3 support in the coming months). Using Jenkins should make all of this pretty trivial as-is.
      - mikepurvis 12y ago
        The dependency caching is orthogonal to bottling; it's just that there's little incentive for me or anyone else to set up or document the bottling process (for ROS on OS X) until the created bottles are usable, which is not presently the case.
- mikemcquaid 12y ago
  It's also worth noting that what you've mentioned about "caching dependencies" isn't caching them on disk (we do that already and extensively) but instead being able to cache it in memory to make dependency resolution faster. I don't think that's basic stuff and most users don't seem to have a problem with the speed of such things.
  - mikepurvis 12y ago
    The current arrangement works great for relatively shallow dependency trees; since that's what most homebrew packages have, it's not a big deal. Having this support in freebsd/pkg may make it a better choice for distributing software on OS X with dependency resolution needs more along the lines of what apt and yum are able to provide.
Argorak 12y ago
Both brew and macports provide that nowadays. I still see an advantage in using a package manager that is used for a full distro, allowing for easier management of packages. I am aware that this benefit might never materialize, but it's good some people try.

ics 12y ago

This might not answer your question completely, but here's a thread from the last time I recall this discussion happening: https://news.ycombinator.com/item?id=8402542 https://news.ycombinator.com/item?id=8402542 It's been a while since I used MacPorts, but I imagine there is some benefit to using the same packaging system between OSs and not having all package descriptions as executable ruby scripts.

emaste 12y ago

This change was written by Landon Fuller, one of the founders of MacPorts. There's an explanation for it in a comment on the pull request: https://github.com/freebsd/pkg/pull/1113#issuecomment-68063964 https://github.com/freebsd/pkg/pull/1113#issuecomment-680639... This change doesn't mean very much in isolation, but will hopefully be the beginning of some interesting collaboration by packagers on both platforms.

tootie 12y ago

It's good to combine efforts. It means potentially a bigger selection of packages that are available to install and more developers maintaining the project since it now has a wider potential user base.

tomphoolery 12y ago

IMHO, Homebrew offers a lot of advantages over traditional package management tools. It's simple to use, offers a really easy way to add your own packages, and contributing upstream is quite painless. MacPorts has always been reminiscent (to me, anyways) of the FreeBSD Ports Collection...it might even be based on it I'm not sure. So this seems like a prelude to a possible sunsetting of the MacPorts project in favor of simply using FreeBSD's package management tools on OS X. Not sure it's going to draw me away from using Homebrew just yet, but it's nice to know that there's a continuing effort to have OS X be a part of the UNIX-like OS community. (fake edit: it's been a LONG time since I've used FreeBSD. feel free to chime in about how wrong I am regarding the ease of adding ports on your own private or public server if things have changed)

JonathonW 12y ago
I don't think MacPorts is a direct derivative of the FreeBSD Ports Collection (someone can correct me if I'm wrong), but it's definitely inspired by FreeBSD Ports-- one of the original MacPorts coauthors (Jordan Hubbard) was the original developer of FreeBSD Ports. I won't be switching anytime soon, though. I moved to Homebrew a long time ago and haven't looked back-- MacPorts feels opaque and isolated in comparison.
- yborg 12y ago
  >MacPorts feels opaque and isolated in comparison What does this even mean? If it means "uncool" then, yeah, I get it. If you are comfortable with Ruby, then it is easier to build packages for Homebrew, and since it isn't centrally managed like MacPorts, things generally get packaged quicker for Homebrew. On the other hand, MacPorts has a long track record and has generally been bombproof for me across 3 or 4 OS updates now. As an existing MacPorts user, I looked at it from the standpoint of "what is this doing for me that MacPorts doesn't?" I didn't see anything that seemed compelling enough to switch.
  - Camillo 12y ago
    I switched to Homebrew a long time ago, when MacPorts had a large advantage in number of packages, freshness, stability etc. For me, MacPorts' main mistake was to go all in with the "storage is cheap, CPU is cheap" canard just as everyone was abandoning desktops for laptops. MacPorts decided to build its own copy of almost everything that the OS distribution provides, to avoid having to deal with version differences between OS X releases. That might have been a decent tradeoff on a Mac Pro, but when you have a laptop with a small HD (and, later, an even smaller SSD), it is a real issue to have to permanently waste several GB on duplicate copies of Perl, Python etc. just because you want to build the GIMP; to say nothing of the hours it would take to build them. Homebrew's big selling point, for me, was that it could just use the libraries that already came with OS X.

mkhpalm 12y ago

Mainly just another sign for Apple that says: "Welcome to the 21st century! In this *nix era we have package managers!"