Interesting! What is the advantage of the FreeBSD package manager over existing OS X package managers like Homebrew or MacPorts?
This change doesn't mean very much in isolation, but will hopefully be the beginning of some interesting collaboration by packagers on both platforms.
(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)
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.
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.
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.
FWIW, nowadays (for a few years?) macports has binary packages, so that is not as big an issue as it used to be, i.e. installing ImageMagick would take hours, now it just usually gets all of the packages and dependencies as binaries.
I think used space is not a huge problem either (I have 130 packages and it uses 1GB), the real issue is that it's anti-intuitive that macports does not remove inactive stuff and does not autoclean, so you end up with a lot of wasted space for stuff you had no interest in keeping.
I think the world sort of moved on from MacPorts and honestly I think it's a few years too late for big OpenSource package system to come to Mac OS. I think that Apple is on a long term course that excludes (or perhaps confines or quarantines) Open Source. I also think that package management is really behind the curve in a computer science sense and a 'next, next-generation package manager' needs to come about.
I'm looking forward to this new package manager alternative.
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.
https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
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).
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.
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.
You can go a step further with this by using the `brew test-bot.rb` script (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!
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.
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.
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.