Live data from Hacker News

Baseline Mac OS X Support merged into FreeBSD package manager

github.com

21–30 of 61 posts

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#21

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

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 o…

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.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#22
post #7

This is great news. Pkgng is very easy to use and achieves a very good combination of binary packages and the FreeBSD ports tree when you want to compile stuff yourself. Which happens more often than expected admittedly.

You can already have that with pkgsrc for osx - joyent maintains the osx binary packages see http://pkgsrc.joyent.com/ (pkgsrc is the NetBSD version of FreeBSD ports, but its always been portable to other systems).

I recently installed pkgsrc for osx, and so far so good. (I've never liked the idea of installing software by compiling it.)

However this project could really use some nice webpages and instructions to promote it. It seems like most Mac devs have never heard of it. And much of the info is pretty minimal and seems like it assumes you understand NetBSD packaging.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#23

Earlier quoted context omitted.

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 o…

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.

>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.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#24
post #15

Naive question: does the pkg(7) format used by FreeBSD have anything to do with the .pkg files Apple distributes? And if not, why not try to be "OSX native" using .pkg files instead of "BSD native" using pkg(7)?

No, Apple's .pkg files are proprietary to Apple's Installer.app. They are XAR archives containing metadata generated by the package creation GUI.

It goes back to the NextStep days too.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#26
post #7

This is great news. Pkgng is very easy to use and achieves a very good combination of binary packages and the FreeBSD ports tree when you want to compile stuff yourself. Which happens more often than expected admittedly.

You can already have that with pkgsrc for osx - joyent maintains the osx binary packages see http://pkgsrc.joyent.com/ (pkgsrc is the NetBSD version of FreeBSD ports, but its always been portable to other systems).

For an introduction to pkgsrc on Mac OS X, please check : http://www.cambus.net/using-pkgsrc-on-mac-os-x/

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#27

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

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 o…

I used MacPorts for years and eventually gave up and abandoned it for Homebrew. It simply became too common that I would come across a project which had directions for setting things up with Homebrew and when I went to try to do it using MacPorts a required package would be missing, outdated, or broken.

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.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#28
post #23

Earlier quoted context omitted.

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.

>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 upda…

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.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#29
post #17

Earlier quoted context omitted.

You can already have that with pkgsrc for osx - joyent maintains the osx binary packages see http://pkgsrc.joyent.com/ (pkgsrc is the NetBSD version of FreeBSD ports, but its always been portable to other systems).

Hmm I didn't know that Joyent maintained their own packages for non-SmartOS platforms. The OS X packages seem to be limited to 32-bit versions and even though you didn't mention this I noticed their Linux packages seem to lag behind pkgsrc upstream. What is the advantage of using their packages over the OS X and Linux ones offered by NetBSD? https://www.pkgsrc.org/#platforms

AFAIK they are the only binary build at present for OSX. You can use source for 64 bit OSX of course http://wiki.netbsd.org/pkgsrc/pkgsrc_64bit_osx/

I have generally used source not packages for non NetBSD platforms, other than when I tried out SmartOS and it is all set up. If you have a chunk of disk space, a fast computer and some time you can compile them yourself, and if someone wants to support osx 64 bit that would be great.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#30

Earlier quoted context omitted.

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

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 ).

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/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!

Post reply on HN