Skip to content
This repository
Browse code

curl 7.21.2 (OS X 10.5 comes with 7.16.3)

CouchDB requires at least 7.18.0.
  • Loading branch information...
commit fd70ad49012be75c532b7991d1a1f0264a0ec91f 1 parent bdb9280
Adam Vandenberg authored December 17, 2009
13  Library/Formula/curl.rb
... ...
@@ -0,0 +1,13 @@
  1
+require 'formula'
  2
+
  3
+class Curl <Formula
  4
+  url 'http://curl.haxx.se/download/curl-7.21.2.tar.bz2'
  5
+  homepage 'http://curl.haxx.se/'
  6
+  md5 'ca96df88e044c7c25d19692ec8b250b2'
  7
+
  8
+  def install
  9
+    system "./configure", "--disable-debug", "--disable-dependency-tracking",
  10
+                          "--prefix=#{prefix}"
  11
+    system "make install"
  12
+  end
  13
+end
5  Library/Formula/libnet.rb
@@ -10,8 +10,9 @@ def install
10 10
     cd 'libnet'
11 11
     inreplace "autogen.sh", "libtoolize", "glibtoolize"
12 12
     system "./autogen.sh"
13  
-    cp "/usr/share/libtool/config/config.guess", "."
14  
-    cp "/usr/share/libtool/config/config.sub", "."
  13
+    # These are being linked in here for us...?
  14
+    # cp "/usr/share/libtool/config/config.guess", "."
  15
+    # cp "/usr/share/libtool/config/config.sub", "."
15 16
     system "./configure", "--prefix=#{prefix}", "--disable-debug", "--disable-dependency-tracking"
16 17
     touch 'doc/man/man3/libnet.3'
17 18
     system "make install"
5  Library/Formula/spidermonkey.rb
@@ -42,8 +42,11 @@ def install
42 42
       # building like this. See: http://openradar.appspot.com/7209349
43 43
       inreplace "configure.in", "LDFLAGS=\"$LDFLAGS -framework Cocoa\"", ""
44 44
       system "#{ac213_prefix}/bin/autoconf213"
  45
+
45 46
       # Remove the broken *(for anyone but FF) install_name
46  
-      inreplace "config/rules.mk", "-install_name @executable_path/$(SHARED_LIBRARY) ", "-install_name #{lib}/$(SHARED_LIBRARY) "
  47
+      inreplace "config/rules.mk",
  48
+        "-install_name @executable_path/$(SHARED_LIBRARY) ", 
  49
+        "-install_name #{lib}/$(SHARED_LIBRARY) "
47 50
     end
48 51
 
49 52
     mkdir "brew-build"

16 notes on commit fd70ad4

Lee Packham

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?

Adam Vandenberg
Owner

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

Adam Vandenberg
Owner

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

Max Howell
Owner

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.

Adam Vandenberg
Owner

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

Mike McQuaid

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.

Adam Vandenberg
Owner

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

Max Howell
Owner

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

Max Howell
Owner

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.

Dreamcat4

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.

Lee Packham

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.

Adam Vandenberg
Owner

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.

Charlie Sharpsteen
Owner

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.

Charlie Sharpsteen
Owner

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.

Adam Vandenberg
Owner

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

Mike McQuaid

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

Please sign in to comment.
Something went wrong with that request. Please try again.