

Baseline Mac OS X Support merged into FreeBSD package manager - emaste
https://github.com/freebsd/pkg/pull/1113

======
jherdman
This pull request is a thing of beauty. Each commit is a little slice of
(mostly) independent awesome. The project nerd in me just did a little dance.

~~~
lumpypua
How the fuck do people do this with git? I loved doing pretty commits with
mercurial's patch queue. Git is awesome but it seems like the only option for
pretty commits is rebase (ew). All the git patch queue implementations are
basically dead or unmaintained. :(

~~~
seivadmas
I haven't used it much so please forgive my ignorance, but what is wrong with
git rebase?

~~~
Nullabillity
Rewrites history. Also, Mercurial allows you to version control your patch
queue (WIP commits).

~~~
thoughtpolice
How is this different from the information stored in `git reflog`, which
allows you to rollback to commits before their rebase? You can just as easily
revert back to the old version, since it never goes anywhere.

Besides, the need to perfectly preserve history in most cases is totally
overblown AFAICS, especially local history nobody else sees. I don't care if a
person who submitted patches to me made 20 separate minor commits to fix minor
things in some case like a code review (e.g. "fix spelling", "fix 80 column
violations", "rename this thing", "clean up code a bit and make it shorter re:
code review"); those are superfluous and add no meaning to the actual work
itself and can be rebased/squashed away in almost all cases. If they submit 20
minor commits that are each independent of one another and isolated, that's
another story.

The alternative seems to just be 'have an ugly history littered with these
commits' if "rewriting history" is so incredibly dangerous/terrible like it is
always implied (which it is not, because you can always recover from it with
the reflog until you push). But I'd rather keep my project history clean and
clear; a tidy history is just as important as tidy code IMO. FWIW, I think the
OP's set of patches are clear and do not constitute an ugly history.

The actual way to 'stop rewriting history' is to disable --force pushes, which
_does_ unilaterally rewrite history for all downstream consumers. This is also
true for Mercurial. Rebase does not do this, or anything close to it.

As someone who reads and writes a lot of patches, this is an exceedingly
common workflow. How is Mercurial any better in this situation where I _don
't_ want all that useless information?

~~~
Nullabillity
> How is this different from the information stored in `git reflog`, which
> allows you to rollback to commits before their rebase? You can just as
> easily revert back to the old version, since it never goes anywhere.

Patch queues make the distinction between mutable WIP patches and finished
commits explicit. Also, versioned patch queues make it safe to share WIP
patches.

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

~~~
tomphoolery
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)

~~~
patrickmay
I've stayed away from Homebrew because of its insistence on taking over
/usr/local. I understand the reasoning, but I use /usr/local for my own
installs and Homebrew doesn't play nicely in that kind of mixed environment. I
would use it if it defaulted to /opt/homebrew or something similar.

I'm looking forward to this new package manager alternative.

~~~
Camillo
You can install Homebrew in a different place if you want. I have an install
inside my home directory.

~~~
patrickmay
How does it work in practice? I tried it about a year ago and it still stomped
on /usr/local for some packages. If I remember correctly, that was due in part
to the package not making it easy to install elsewhere, but Homebrew didn't
handle it well.

~~~
tomphoolery
It definitely shouldn't do that. Most likely that's a fault with the way the
formula or Makefile is written, like hardcoding `/usr/local` instead of using
$PREFIX.

------
_wmd
NetBSD pkgsrc has supported OS X for almost a decade now, including a complete
binary build IIRC thanks to Joyent

------
derefr
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)?

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

~~~
SG-
It goes back to the NextStep days too.

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

~~~
justincormack
You can already have that with pkgsrc for osx - joyent maintains the osx
binary packages see [http://pkgsrc.joyent.com/](http://pkgsrc.joyent.com/)

(pkgsrc is the NetBSD version of FreeBSD ports, but its always been portable
to other systems).

~~~
avtar
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](https://www.pkgsrc.org/#platforms)

~~~
yrmt
I'm building fresh 64bit packages on Mac OS X Yosemite. They will be uploaded
in a few days at
[http://pkgsrc.saveosx.org/Darwin/2014Q4/x86_64/All/](http://pkgsrc.saveosx.org/Darwin/2014Q4/x86_64/All/).
Oh and they are GPG signed. Documentation at
[http://saveosx.org](http://saveosx.org)

------
lookrealclose
BSD ports on Yosemite, what could go wrong LOL!

