Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

Commit

Permalink
curl 7.21.2 (OS X 10.5 comes with 7.16.3)
Browse files Browse the repository at this point in the history 
CouchDB requires at least 7.18.0.
  • Loading branch information
@adamv
adamv committed Nov 9, 2010
1 parent bdb9280 commit fd70ad4
Show file tree
Hide file tree
Showing 3 changed files with 20 additions and 3 deletions.
13 changes: 13 additions & 0 deletions Library/Formula/curl.rb
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
require 'formula'

class Curl <Formula
url 'http://curl.haxx.se/download/curl-7.21.2.tar.bz2'
homepage 'http://curl.haxx.se/'
md5 'ca96df88e044c7c25d19692ec8b250b2'

def install
system "./configure", "--disable-debug", "--disable-dependency-tracking",
"--prefix=#{prefix}"
system "make install"
end
end
5 changes: 3 additions & 2 deletions Library/Formula/libnet.rb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,9 @@ def install
cd 'libnet'
inreplace "autogen.sh", "libtoolize", "glibtoolize"
system "./autogen.sh"
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"
Expand Down
5 changes: 4 additions & 1 deletion Library/Formula/spidermonkey.rb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -42,8 +42,11 @@ def install
# building like this. See: http://openradar.appspot.com/7209349
inreplace "configure.in", "LDFLAGS=\"$LDFLAGS -framework Cocoa\"", ""
system "#{ac213_prefix}/bin/autoconf213"

# Remove the broken *(for anyone but FF) install_name
inreplace "config/rules.mk", "-install_name @executable_path/$(SHARED_LIBRARY) ", "-install_name #{lib}/$(SHARED_LIBRARY) "
inreplace "config/rules.mk",
"-install_name @executable_path/$(SHARED_LIBRARY) ",
"-install_name #{lib}/$(SHARED_LIBRARY) "
end

mkdir "brew-build"
Expand Down

16 comments on commit fd70ad4

@leepa
Copy link
Contributor

@leepa leepa commented on fd70ad4 Nov 9, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 9, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@adamv
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 9, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

@mxcl mxcl commented on fd70ad4 Nov 14, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 14, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@MikeMcQuaid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

@mxcl mxcl commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

@mxcl mxcl commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

@leepa leepa commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Sharpie
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Sharpie
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@adamv adamv commented on fd70ad4 Nov 15, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@MikeMcQuaid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Please sign in to comment.