Browse files

curl 7.21.2 (OS X 10.5 comes with 7.16.3)

CouchDB requires at least 7.18.0.
  • Loading branch information...
1 parent bdb9280 commit fd70ad49012be75c532b7991d1a1f0264a0ec91f @adamv adamv committed Dec 17, 2009
Showing with 20 additions and 3 deletions.
  1. +13 −0 Library/Formula/curl.rb
  2. +3 −2 Library/Formula/libnet.rb
  3. +4 −1 Library/Formula/spidermonkey.rb
@@ -0,0 +1,13 @@
+require 'formula'
+class Curl <Formula
+ url ''
+ homepage ''
+ md5 'ca96df88e044c7c25d19692ec8b250b2'
+ def install
+ system "./configure", "--disable-debug", "--disable-dependency-tracking",
+ "--prefix=#{prefix}"
+ system "make install"
+ end
@@ -10,8 +10,9 @@ def install
cd 'libnet'
inreplace "", "libtoolize", "glibtoolize"
system "./"
- cp "/usr/share/libtool/config/config.guess", "."
- cp "/usr/share/libtool/config/config.sub", "."
+ # These are being linked in here for us...?
+ # cp "/usr/share/libtool/config/config.guess", "."
+ # cp "/usr/share/libtool/config/config.sub", "."
system "./configure", "--prefix=#{prefix}", "--disable-debug", "--disable-dependency-tracking"
touch 'doc/man/man3/libnet.3'
system "make install"
@@ -42,8 +42,11 @@ def install
# building like this. See:
inreplace "", "LDFLAGS=\"$LDFLAGS -framework Cocoa\"", ""
system "#{ac213_prefix}/bin/autoconf213"
# Remove the broken *(for anyone but FF) install_name
- inreplace "config/", "-install_name @executable_path/$(SHARED_LIBRARY) ", "-install_name #{lib}/$(SHARED_LIBRARY) "
+ inreplace "config/",
+ "-install_name @executable_path/$(SHARED_LIBRARY) ",
+ "-install_name #{lib}/$(SHARED_LIBRARY) "
mkdir "brew-build"

16 comments on commit fd70ad4

leepa commented on fd70ad4 Nov 9, 2010

Does curl need linking for coucdb or could it cope with being keg'd so that other things being built don't link against it?

adamv commented on fd70ad4 Nov 9, 2010

Crap, curl was supposed to be keg-only here; looks like I pulled the wrong commit.

adamv commented on fd70ad4 Nov 9, 2010

Pushed an update for curl, but don't have 10.5 here to test; will test tonight. CouchDB only sets the dep on 10.5, though, so 10.6 should be "safe".

mxcl commented on fd70ad4 Nov 14, 2010

We shouldn't have new formula for dupes. At all.

This should have been included inline in the couchdb formula if it requires it IMO.

If this is a common sort of thing now, maybe we should have a formula directory that is dupes and these formula can only be used as deps, and only install keg only.

adamv commented on fd70ad4 Nov 14, 2010

@mxcl - I can redact this and add explicit install steps for Leopard in the CouchDB formula if you think it would be better.


Max: good ideas there, I agree. Also, if a formula is only for 10.5 in this regard, perhaps try and make sure we check that too.

adamv commented on fd70ad4 Nov 15, 2010

Cairo and FontConfig are existing keg-only formula only in place for Leopard; see gtk+ and pango. They guard the dep with "... if MACOS_VERSION < 10.6".

mxcl commented on fd70ad4 Nov 15, 2010

We should do what I said, but I can imagine it would be a PITA, so for now, leave it (your option). However we should think on:

  1. a DupeFormula directory that formula can depend on. Everything installed from here goes into a DupeCellar or something less stupid and then formula just have to be able to link against this.
  1. We provide a .pkg that upgrades some of OS X's core libraries that are old and manky.

2 is better for support. But is that really the route we want to go? I think more and more that it is, because dupes suck and break stuff and violate our policy and mean we are maintaining dupes and etc. and having broken libs on your system is daft too.

Further to this area, what is our 10.5 userbase like do we know? When do we stop supporting it in mxcl master? Lion is due next year.

mxcl commented on fd70ad4 Nov 15, 2010

However, IMO, going forward dupes (when required) should be done as formula inside other formula files, installed in a fashion so they are not linked into the main prefix. Otherwise we are just encouraging the continued creation of more dupes, and ultimately that will lead us to a mess. We have to stick to our guns or we should never have started.


The problem with option 2 is it would be open to over-patching. Any core osx libraries homebrew might wish to update can be overwritten and regress back (or get broken) during subsequent Apple Software updates.

I agree that max's original idea seems the most sensible. Somebody (who still uses 10.5 Leopard!) needs to make a new commit for the couchdb formula. With these above dependencies inlined by "if MACOS_VERSION < 10.6".

OTOH maybe theres nobody here who still uses couchdb on 10.5 Leopard... Or nobody who can be bothered to contribute the extra cruft for it. Well then thats absolutely fine too. Most of us (the masses! - like 99%) all use 10.6 Snowy Leopard now therefore unaffected. Its not to say receiving such backwards-compatibility-patches wouldn't still be a welcome addition to homebrew.

leepa commented on fd70ad4 Nov 15, 2010

What the hell did I start!?

Personally I would drop 10.5 - 10.6 is already up to it's 5th OS update and if you want to do software development of iOS and the like, you have to be on it. I can understand business class users stuck on 10.5, but not developers. We have a growing number of quirks now for that version of the OS. As such - I would also propose that we deprecate support for 10.5 in master.

adamv commented on fd70ad4 Nov 15, 2010

Note that the Leopard support here is just "formulas that are duped in Snow Leopard", not core changes. One of the things I have on the back-burner is "multi-repo support"; on hold a bit because of the refactor in progress.

If we come up with a sane multi-repo story, then when Lion comes out we move the Leopard support formulae to a separate repo, kind of like how the Duplicates branch is separate, but with separate support for switching off.

Someone did try to install CouchDB on Leopard or I wouldn't have tweaked this in the first place, using the same pattern already in place for say GTK+.

And of course Homebrew is mentioned in the CouchDB book itself as the best way to install on OS X, and not everyone is on 10.6.

So after refactor lands, I'll hack some more on multi-repo support and then we can think about moving out Leopard brews or whatever.


I think the best long term solution would be multi-repository support. Then we could start migrating the brews with a lot of 10.5 support code and issues into a 10.5 branch.

In the near term, some ideas:

  • Run a poll to see what percentage of Leopard users we have.
  • Repack XCode 3.1.4 as it is unlikely to receive a significant update. Any development libraries that need to be upgraded could be fixed at this point without causing dupes. I am willing to dig into the XCode .pkg and see what is really necessary to run Homebrew.
  • Add a leopard_maintenance_required flag or something similar that lets the community know that someone needs to step forward and give a brew some major TLC if it is to continue functioning under Leopard.

If we come up with a sane multi-repo story, then when Lion comes out we move the Leopard support formulae to a separate repo, kind of like how the Duplicates branch is separate, but with separate support for switching off.

I just had a small brainstorm about multi-repo support as well. It seems like it might be nice to hash out an implementation plan for this feature while the refactor is underway. This would help some of us share the coding burden when it comes time to implement.

adamv commented on fd70ad4 Nov 15, 2010

@Sharpie: the take so far: "install from url/path" means formula takes a path now, so we can track where a formula came from. This will define its "repo". Deps from a formula will resolve first from the same repo, then fall back to master.

At this point, lets move the conversation to the mailing list or other appropriate venue.


Yep, I'm up for further discussion about this on the list if anyone wants to kick it off.

Please sign in to comment.