8 ms·

Baseline Mac OS X Support merged into FreeBSD package manager

229 points by emaste 12y ago

santaclaus 12y ago
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!"
aduitsis 12y ago
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 12y ago
  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 12y ago
    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
    - justincormack 12y ago
      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/ 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.
    - yrmt 12y ago
      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
jherdman 12y ago
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.
- brunosutic 12y ago
  That guy seriously rules.
- pvaibhav2 12y ago
  I've found this to be true for most of FreeBSD and even other BSD-licensed code.
- lumpypua 12y ago
  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 12y ago
    I haven't used it much so please forgive my ignorance, but what is wrong with git rebase?
    - Nullabillity 12y ago
      Rewrites history. Also, Mercurial allows you to version control your patch queue (WIP commits).
      - thoughtpolice 12y ago
        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?
deleted 12y ago
[deleted]
derefr 12y ago
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 12y ago
  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- 12y ago
    It goes back to the NextStep days too.
- brynet 12y ago
  FreeBSD's binary packages aren't .pkg, but rather .txz (.tar + .xz). http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/2bsd-diff-2.11.txz http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/2bsd-dif...: -rw-r--r-- 1 root wheel 626 Dec 31 1969 +COMPACT_MANIFEST -rw-r--r-- 1 root wheel 921 Dec 31 1969 +MANIFEST tar: Removing leading / from absolute path names in the archive -r-xr-xr-x 1 root wheel 30616 Oct 3 10:49 usr/local/bin/2diff -r-xr-xr-x 1 root wheel 11256 Oct 3 10:49 usr/local/libexec/2diffh -r--r--r-- 1 root wheel 2823 Oct 3 10:49 usr/local/man/man1/2diff.1.gz This is similar to other BSD binary package formats.
lookrealclose 12y ago
BSD ports on Yosemite, what could go wrong LOL!
_wmd 12y ago
NetBSD pkgsrc has supported OS X for almost a decade now, including a complete binary build IIRC thanks to Joyent

229 points by emaste 12y ago

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

aduitsis 12y ago

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 12y ago
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 12y ago
  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
  - justincormack 12y ago
    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/ 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.
  - yrmt 12y ago
    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

jherdman 12y ago

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.

brunosutic 12y ago
That guy seriously rules.
pvaibhav2 12y ago
I've found this to be true for most of FreeBSD and even other BSD-licensed code.
lumpypua 12y ago
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 12y ago
  I haven't used it much so please forgive my ignorance, but what is wrong with git rebase?
  - Nullabillity 12y ago
    Rewrites history. Also, Mercurial allows you to version control your patch queue (WIP commits).
    - thoughtpolice 12y ago
      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?

deleted 12y ago

[deleted]

derefr 12y ago

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 12y ago
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- 12y ago
  It goes back to the NextStep days too.
brynet 12y ago
FreeBSD's binary packages aren't .pkg, but rather .txz (.tar + .xz). http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/2bsd-diff-2.11.txz http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/2bsd-dif...: -rw-r--r-- 1 root wheel 626 Dec 31 1969 +COMPACT_MANIFEST -rw-r--r-- 1 root wheel 921 Dec 31 1969 +MANIFEST tar: Removing leading / from absolute path names in the archive -r-xr-xr-x 1 root wheel 30616 Oct 3 10:49 usr/local/bin/2diff -r-xr-xr-x 1 root wheel 11256 Oct 3 10:49 usr/local/libexec/2diffh -r--r--r-- 1 root wheel 2823 Oct 3 10:49 usr/local/man/man1/2diff.1.gz This is similar to other BSD binary package formats.

lookrealclose 12y ago

BSD ports on Yosemite, what could go wrong LOL!

_wmd 12y ago

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