From owner-freebsd-ports@FreeBSD.ORG Thu Aug 6 03:38:11 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FBAB106566B for ; Thu, 6 Aug 2009 03:38:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2429F8FC17 for ; Thu, 6 Aug 2009 03:38:11 +0000 (UTC) Received: (qmail 23849 invoked by uid 399); 6 Aug 2009 03:38:07 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 6 Aug 2009 03:38:07 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A7A5018.1050108@FreeBSD.org> Date: Wed, 05 Aug 2009 20:38:00 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Scott Bennett References: <200908051052.n75AqSAI005906@mp.cs.niu.edu> In-Reply-To: <200908051052.n75AqSAI005906@mp.cs.niu.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: getting bogged down by malfunctioning ports subsystem X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 03:38:11 -0000 Scott Bennett wrote: > Yesterday's ports updates are just *loads* of fun. :-( Until portmaster > reached the rebuilding of perl5.10, *every* *single* *port* that got rebuilt > ended in failure on a "make deinstall/make reinstall" recommendation, *none* > of which actually worked when tried. You've heard the definition of insanity right? Doing the same thing over and over and expecting a different result? If you're having problems like this it's a good idea to report them sooner than later. Unless you can give specifics it's basically impossible to help you. > The only thing that worked was to ignore > that part of the recommendation and instead to do a > "env FORCE_PKG_REGISTER make install". I didn't isolate that until after > several rebuilt ports (mostly qt4- ports) were lost due to the failures of > the recommended solution. Personally I have had good luck with FORCE_PKG_REGISTER in these situations, although it's probably worth noting for the record that this recommendation comes from the ports infrastructure, not portmaster. I would also like to point out that if you have problems with *every* *single* *port* you might want to consider that you have a more systemic problem with your particular pkg directory having become corrupt, or something else on a grander scale than just "the ports subsystem sucks." > perl5.10, however, now fails to update on something different. It gets > an error that says, > > . > . > . > ===>>> Starting check for runtime dependencies > ===>>> Gathering dependency list for lang/perl5.10 from ports > ===>>> Starting dependency check > ===>>> Checking dependency: /usr/ports/databases/gdbm > ===>>> Dependency check complete for lang/perl5.10 > > /usr/bin/make install.perl install.man STRIPFLAGS= DESTDIR="" > /usr/bin/strip: '/usr/local/bin/perl5.10.0': No such file > /usr/bin/strip: '/usr/local/bin/perl': No such file > /usr/local/bin/pod2man: not found > *** Error code 127 > > It then proceeds to rebuild the port and install much of it before failing > with > > 1 error In a situation like this what I would do is 'pkg_delete -f' the port, then immediately rebuild it with portmaster again (so that portmaster can register the dependencies properly when it installs). I agree that is not "graceful," but the perl (and as I understand it python as well) stuff is notoriously twitchy when it comes to these kinds of problems. I have considered changing the order of how portmaster does things from: build backup package (unless -B) deinstall install to: backup package deinstall build install That is undoubtedly more dangerous, and would require the "automated backout" feature that I have yet to write, but it would solve a lot of these problems. -- This .signature sanitized for your protection