You ever have one of those days where both of the major open-source package management systems fail on you for the same package?
I need secure subversion to handle checking out a project with an https://-style URL. I currently have version 1.1.4 of the non-ssl svn client installed via fink.
So…
cadamson% sudo fink install svn-client-ssl
Failed: This package must be compiled with GCC 4.0.0, but you currently have
GCC 4.0.1 selected. To correct this problem, run the command:
sudo gcc_select 4.0
(You may need to install a more recent version of the Developer Tools to be able to do so.)
Ohhh kay.
Next contestant: Darwin Ports. Potentially cooler anyways, because whereas fink’s stable version of svn-client-ssl is of the 1.2 series, Darwin Ports’ version of the whole subversion kielbasa is at 1.3. Plus, the DP approach is recommended by Apple.
So, I download Darwin Ports, adjust my path to put /opt/local/bin ahead of Fink’s /sw/bin, and try:
sudo port install subversion
And the result is:
Error: Checksum (md5) mismatch for db-4.3.29.tar.gz
Error: Target com.apple.checksum returned: Unable to verify file checksums
Error: The following dependencies failed to build: apr-util db4 expat libiconv neon openssl zlib
Error: /opt/local/bin/port: Status 1 encountered during processing.
Ouch. Subversion, the favorite source control system of many serious developers, doesn’t build today on either of the Mac package managers.
That is why I stopped using the Mac package managers. Plus, a conversation on IRC with one of the developers of Fink where he stated he would not use it in a production environment. If you just need the svn client compiling from source is a piece of cake.
Just fetch the subversion source yourself, do a
./configure --with-prefix=/usr --with-ssl
make
sudo make install
and you're done. I've always prefered direct control... ;)
I switched to using Martin Ott's (of TheCodingMonkeys) svn package
http://codingmonkeys.de/mbo/
It's already built for you, all you have to do is install it. You also don't have to deal with all the deps that the fink/dp packages force you to install.
"Plus the DP approach is recommended by Apple"
interesting. With xcode 2.0 they suggeested using Fink.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeUserGuide20/Contents/Resources/en.lproj/UsingSubversion/chapter_50_section_2.html
Either compile svn yourself (not difficult) or download a pre-compiled package from http://www.codingmonkeys.de/mbo/ and get a no-trouble installer.
Yes, avoiding the package managers is good for things with simple dependencies, but for some of the things I've installed, that would require me hunting down ten or twenty other packages (particularly anything that uses gnome). I'm very happy for fink and darwinports, even though they break from time to time.
I used Fink for a while, but it's fairly bloated. Darwin Ports seems less interested in duplicating infrastructure that's already available in OS X.
For a while I did go manager-less, but after building and installing ImageMagick myself I decided maybe the package managers have their place on my computer. :-D
I try to avoid Fink whenever possible, as it does a poor job of checking dependencies. It does not consider any other libraries other than ones installed in /sw. Thsu, you end up with multiple redundant copies of some libs. I prefer to have everything in /usr or /usr/local.
Wait. So why didn't you just run the gcc_select command? (I'm only asking because I would have assumed that to be the easiest thing to do -- I do it all the time and it seems to work out)
i clicked a link to read this? it tells you to gcc_select. Why can't you just do that then ? And to the guy that said "Just compile it from the source", its funny how it sounds so simple when you use the word "Just".
DarwinPorts did exactly what it should've with db-4.3.29. The MD5 of the file on the website has indeed changed.
From my investigation, it seems the licensing has changed on 2 files, and a bunch of java files were removed. The changes were done a couple of days ago.
There's no reason why subversion packages should require db anymore. Subversion defaults to fsfs not bdb. db should only be an option now, not a requirement.
I ran into this same problem today on OpenBSD using its ports system. Passing a different sourceforge mirror to make resolved the issue. I got that idea from the following:
http://marc.theaimsgroup.com/?l=openbsd-ports&m=113880677100205&w=2
Darwinports has worked flawlessly for me for 5 months now. The poster Rob appears to has discovered a flaw in the db package where files were changed recently and the checksum not updated. Darwinports did work correctly.
I have the following darwinports installed (installed over time, dependencies handled flawlessly, some upgraded automatically, no checksum errors, built cleanly):
apache2 @2.2.0_0 (active)
apr @1.2.2_0 (active)
apr-util @1.2.2_0 (active)
audiofile @0.2.6_0 (active)
autoconf @2.59_0 (active)
autogen @5.7.3_0+darwin_8 (active)
automake @1.9.6_0 (active)
db4 @4.3.28_0+darwin_8 (active)
esound @0.2.35_1 (active)
expat @1.95.8_1 (active)
gettext @0.14.5_0 (active)
guile @1.6.7_0+darwin_8 (active)
ImageMagick @6.2.4-3_2 (active)
jpeg @6b_1 (active)
libiconv @1.10_1+darwin_8 (active)
libmikmod @3.1.11a_0 (active)
libogg @1.1.2_0 (active)
libpng @1.2.8_2+darwin_8 (active)
libsdl @1.2.8_3+darwin_8 (active)
libsdl_mixer @1.2.6_3 (active)
libtool @1.5.20_0 (active)
libvorbis @1.1.0_0 (active)
neon @0.24.7_0
neon @0.25.4_0 (active)
opensp @1.5.1_0 (active)
openssl @0.9.8a_0+darwin_8 (active)
pcre @6.4_0 (active)
py-ipython @0.7.0_0 (active)
py-pyobjc @1.3.7_0 (active)
py-readline @2.4.2_0 (active)
py-wxpython @2.6.1.0_0 (active)
python24 @2.4.2_1+darwin_8 (active)
readline @5.0.005_0+darwin_8 (active)
smpeg @0.4.4_6+darwin_8 (active)
subversion @1.2.3_1
subversion @1.3.0_2 (active)
tiff @3.8.0_0+darwin_8 (active)
wxWidgets @2.6.2_0+darwin_8 (active)
zlib @1.2.3_0 (active)
You can see that subversion was upgraded cleanly.
I would now recommend darwinports over fink, which I've used in the past. It "just works" for me in every case so far and I feel it's very reliably way of getting unix-based software installed cleanly.
The next port I'm switching to is postgresql8 to replace the version installed with an OSX installer package to /Library/PostgreSQL8 (done way back).
I some unix applications/utilities but when I need more I now look for a darwinport for OSX.
- John
The md5 has indeed changed. To fix this, just edit the PortFile located in "/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/databases/db4/" and change the md5 checksum with "200b9f5d74175875fcb3ee54adbf0007".
Run "port install" again and it will work fine.
I had the same problem. The MD5 checksum in the Portfile is out of date. It may be an error or maybe sleepcat changed the tar file without updatng the version. Simple fix, edit the Portfile (/opt/local/var/db/dports/sources/rsync.rsync.opendarwin.org_dpupdate_dports/databases/db4/Portfile) and add the correct MD5 (200b9f5d74175875fcb3ee54adbf0007). Remember this is open source, you're expect to try and fix stuff for yourself. ;-)
trouble asks i clicked a link to read this? it tells you to gcc_select. Why can't you just do that then ?Um, because it doesn't work when you do that. And I thought the implicit comedy of an error that says "you have to compile with 4.0.0, you have 4.0.1, so get a newer version of the dev tools" was enough to express how wedged this is.I've since built subversion from source as several have advocated. I also recently wrote about building emacs22 from source, so as soon as I go back and build apache2 from source, I'll probably remove Fink and Darwin Ports from all my machines.
I is time to try pkgsrc.
Even if it is not macosx specific, it does work fine under macosx, as well as other unixes
The problem in DarwinPorts has allegedly been resolved:
http://bugzilla.opendarwin.org/show_bug.cgi?id=7179
Problems like this are what the bug tracker and also the mailing list are for. (The problem has come up four or five times on the list in the past week, so you should have been easily able to find it in the list archives if you had looked there.)
Unless you really think you need db4 (i.e. you have existing BDB repositories and don't want to migrate them to FSFS) you should build Subversion without BDB support:
sudo port install apr-util +no_bdb
sudo port install subversion +no_bdb
Yes, you must do both steps, in that order.
Further discussion of this please to the DarwinPorts mailing list.
Ryan Schmidt writes Problems like this are what the bug tracker and also the mailing list are for. (The problem has come up four or five times on the list in the past week, so you should have been easily able to find it in the list archives if you had looked there.)
I found several checksum-related problems on the DP lists, some from last November. I didn't find (or really look for) this particular bug report. Considering that my last DP bug hung around for three years, it seemed a lot easier to just bail on this than to wait.
Bug on DarwinPorts has already been filed and fixed:
http://bugzilla.opendarwin.org/show_bug.cgi?id=7179
Updated port is now at:
http://subversion.darwinports.com
Jose, what you recommend is foolhardy without knowing the implications. In this case, it's fine, but it's not something you want to do in the general case.
The new MD5 is on the sleepycat website, but it's on the same server as the tarball. That means it's useful for integrity checks, but worthless for security ones.
"Many eyes" worked in this case, because I did the verification of the file. But you want to have a trustworthy source (or check it yourself) when there are changes like this that could indicate compromise.
The problem with darwinports here is sleepycat: They changed an already released tarball on their server. FreeBSD ports also stumbled upon this misbehaviour, as did we; this bug has been fixed and we now - after testing it - use the new tarball.
Uh, aside from Fink the Subversion site links to http://metissian.com/projects/macosx/subversion/ right from the Downloads page. I know you've already solved your problem, but did you look there?
Problems like this are usually fixed very quickly, particularly if you take the time to submit a Bugzilla ticket. Of course, one might get around these (very rare) problems by manually compiling from source, but keeping software and dependencies up-to-date is much more difficult that way. This is discussed in a recent article on Server Codex entitled "Installing DarwinPorts on Mac OS X":
http://www.servercodex.com/archives/2006/02/06/installing-darwinports-tiger/
Justin writes Problems like this are usually fixed very quickly, particularly if you take the time to submit a Bugzilla ticket.
Guess I'm the exception to the "usually", then. The last time I filed a DP bug, it took three years to get resolved. As "LATER" (which, in this case, was the right choice, but still... three years!).
one might get around these (very rare) problems by manually compiling from source, but keeping software and dependencies up-to-date is much more difficult that way
This is maybe the implicit point of my blog and the follow-ups. I've had four consecutive bad experiences with Mac package managers: 1. DP emacs21 unbuildable with X11 and bug not cleared for three years, 2. Fink's apache2 port being either wildly out of date (stable) or unbuildable (unstable) and its maintainer unresponsive to e-mail, 3. Fink unable to build subversion due to a gcc version snit, 4. DP unable to build subversion due to a inadvertent checksum mistake upstream. The solution every time: engage the community, track down the maintainer, fix it yourself, etc. All of which ends up being more work than simply building from source. I'm starting to think that the package management projects have just moved the complexity problem, instead of solving it. That's probably not entirely fair, because the Debian community gets it right, and has for years. But still, at this point, I feel like I'm done with Fink and DP, since I've had better results recently just building things myself... still a hassle, but less hassle than working with the package managers has become.
In my experince pkgsrc is the better solution. You'll probably still find packages in pkgsrc that doesn't compile on OS X, but the success rate is much higher than in DP and fink. See http://www.pkgsrc.org/
The error you got with Fink is caused by an outdated version of the package manager which only understands gcc versions of the form x.y. The 4.0.1 version number confuses it. You need to run "fink selfupdate-rsync" to get the latest version which should be 0.24.10 for the stable tree and 0.24.11 for unstable. And it's really better to use the unstable tree; despite the name, it's usually more stable than stable is. :)
@Sander: I wouldn't generally recommend adding "--with-prefix=/usr" to configure (as in your example) since adding files anywhere under /usr except /usr/local is discouraged on OS X.
Chris: I feel your pain. And a few days before your original post, I filed a DP bug report to prove it.
http://bugzilla.opendarwin.org/show_bug.cgi?id=7034
As you can see from the bug report, the DP system was rendered nearly useless because the zlib.net site went down briefly. If I were compiling manually, I could have simply found zlib on a mirror site, compiled it, and been on my way. It's silly that DP was stymied by a dependency site outage, and it's sillier still that a DP maintainer had the audacity to claim this wasn't a failing on the part of DP. Is DP to blame for the zlib.net site outage? Of course not. Should DP be so dependent on dependency sites that an outage can render DP inoperable? I don't think so.
So yes -- there are definitely improvements that can be made. And if you need the absolute latest versions as quickly as possible, port managers such as DP are probably not the best route. But when you want to be able to regularly upgrade software and dependencies with very little manual labor, I think port managers offer clear advantages.
I've had better results recently just building things myself... still a hassle, but less hassle than working with the package managers has become.
While I see your point, there is one important thing you are missing here: tracking down a maintainer and getting a DP problem fixed benefits *all* DP users, whereas taking the time to manually compile software, troubleshoot dependencies, and stay up-to-date with frequent bug/security fixes only benefits you -- and this hassle must be duplicated by everybody else as well.