From owner-freebsd-ports@FreeBSD.ORG Thu Jun 25 17:48:49 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 451231065672 for ; Thu, 25 Jun 2009 17:48:49 +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 ECD748FC0A for ; Thu, 25 Jun 2009 17:48:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1837 invoked by uid 399); 25 Jun 2009 17:48:47 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Jun 2009 17:48:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A43B87D.6030908@FreeBSD.org> Date: Thu, 25 Jun 2009 10:48:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Scott Bennett References: <200906242222.n5OMM60O011347@mp.cs.niu.edu> In-Reply-To: <200906242222.n5OMM60O011347@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: [REPOST] problem upgrading perl 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, 25 Jun 2009 17:48:49 -0000 Scott Bennett wrote: > On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton > wrote: > There ought to be an automated way to deal with the package issue that > causes the failure of the entire update run just because it wants a human > to type "make deinstall && make reinstall". Sorry I wasn't clear, the inherent problem I described is with perl, not with the ports. Because perl stores its libraries in a file hierarchy based on version number (arguably, a feature) when you do a straight upgrade from one version of perl to another IME the only really good way to do that is to make a list of perl-related stuff you have installed, delete everything, and reinstall. For those that only have a few libraries installed using portmaster/portupgrade -r will probably work, and is certainly worth a try. >> Have you tried using the -x option to exclude it? You can also use the >> -i option, although for a lot of ports that can get annoying. > > I had not, thanks to my having misread something in the portmaster man > page. If you have any suggestions for improving the text I'm open to them. > However, since reading your reply, I have tried (without -R) > > # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3 If this is a literal copy of what you did I'm surprised it worked since you've placed the -v option between the -r and its argument. > which did rebuild perl Yes, I just checked the code and portmaster does not check the -x argument for the main port specified in the command line. I'll take a look at that. > (along with many other already rebuilt ports, of > course). At this moment, I have > > # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3 > > running, and it is currently rebuilding perl yet again. So the -x option > appears to be useless, at least in this context. You might want to be a little more careful with your adjectives. My feelings aren't hurt but when you're asking for help, especially for something you're not paying anything for, words like "useless" tend not to make you any friends. > I began using FreeBSD at 5.2.1. Along the way, my other complaints have > largely been fixed, but the ports subsystem remains to this day the weakest > part of all of FreeBSD. I realize that the problem of coordinating the > installation and maintenance of such a widely diverse body of ports and > packages is a complex one, Having spent a non-trivial amount of time in the bowels of the ports system I would argue that "complex" is a dramatic understatement. > but the problems the current tools, dependency > lists, Makefiles, etc. present to the user are often insoluble by anyone but > an expert in the internal workings of each of the pieces of the subsystem. > The packages subsystem is in about as bad shape, and in spite of the > degree to which the two are intertwined, they really do not play nicely > together. Once again, being more careful with your rhetoric would go a long way here. This is a volunteer project, and no one would argue that there is nothing left to improve. Feel free to roll up your sleeves and get to work. :) Doug -- This .signature sanitized for your protection