From owner-freebsd-ports@FreeBSD.ORG Wed Aug 23 06:30:19 2006 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82DEE16A4DE for ; Wed, 23 Aug 2006 06:30:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 61B5143D6A for ; Wed, 23 Aug 2006 06:30:14 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 14363 invoked by uid 399); 23 Aug 2006 06:30:13 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Aug 2006 06:30:13 -0000 Message-ID: <44EBF5F1.4050802@FreeBSD.org> Date: Tue, 22 Aug 2006 23:30:09 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: "Michael W. Lucas" References: <20060822010628.GA96258@bewilderbeast.blackhelicopters.org> In-Reply-To: <20060822010628.GA96258@bewilderbeast.blackhelicopters.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org Subject: Re: "the best" port update tool 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: Wed, 23 Aug 2006 06:30:19 -0000 I wanted to let some others respond to this post before I did, but now that they have ... Michael W. Lucas wrote: > Hi, > > After a database headache caused by my own doofusity, D'oh, I hate when that happens. :) > A search of the mailing list archive doesn't seem to lead me to a > clear successor or improvement upon portupgrade. Is portupgrade still > as good as it gets, or are we headed towards another tool any time > soon? My view is that portupgrade and portmaster are serving two different audiences, with a non-trivial set of users in common. I rarely ever use pre-built packages, so I don't really plan to duplicate portupgrade's package handling abilities. I also really dislike the idea of external databases, so between that and ruby I never even tried portupgrade myself. Like mergemaster, the portmaster script grew organically out of some simple stuff that I got tired of doing over and over again by hand, and has now evolved to be fairly full featured, in large part as a result of user requests and feedback. IMO portmaster now contains a fairly complete set of tools to manage your ports. Combined with sysutils/portconf you have the same basic functionality of portupgrade without the overhead of external databases or a scripting language that's not in the base. This is not to say that there is anything _wrong_ with portupgrade. If you use it and like it, or more importantly if you need its tools, knock yourself out. As I said above, portmaster isn't for everyone, it's just one possible way to tackle a subset of the problems portupgrade is designed for. Responding to bits of some of the other posts ... Jiawei Ye wrote: > 3) Portmaster > This is what I am using now, Nice to hear! And thanks to the others that had kind things to say about it as well. > along with portconf to define per-port > make flags and options. The only things I miss from portmaster are the > pkg_deinstall ability I think the new -e option, and the enhanced -s option come close to what you're looking for. If you'd like to let me know what else you think we should do here, I'll be glad to think it over. > and an easy way to define alternative dependancies. That turns out to be a rather icky problem, but mezz came up with an interesting idea that I need to work through in more detail, so it's not hopeless. :) > Speed doesn't seem to be a problem compared to > portmanager though it is written as a shell script. Thanks! I have worked pretty hard to try and optimize all the things that portmaster is actually doing, as opposed to time spent waiting for the ports tree. > One feature from portupgrade I would like to see in portmaster is the > ability to go on upgrading other ports if one of them failed. That gets very tricky, since portmaster does a depth first traversal of the dependencies, so if something fails it's very likely that the things "above" it would fail as well. But as always, patches are welcome. :) Scot Hetzel wrote: > While the portmanager, portupgrade, and portmaster tools allow you to > keep your specific port options in a file, Not that it's a major issue, but portmaster does not actually have this feature. > they are incompatible with > each other and when building directly from /usr/ports, as the port > options in these seperate files are not available to the other tools > or to /usr/ports. This deficiency has been fixed with the > sysutils/portconf port, where you can specify your port options in > PREFIX/etc/ports.conf file, and these tools and direct building from > /usr/ports will use these port options. Now this I agree with, portconf is a great tool. > For example if you need a global WRKDIRPREFIX, you can use the > following in the ports.conf file: > > */*: WRKDIRPREFIX=/usr/obj You _could_ do it this way. You could also put your globals in /etc/make.conf. Although the more time goes by, the less comfortable I am with stuff in make.conf. In any case, I hope this helps answer Michael's original question, even if it is more info that he was bargaining for. :) Doug -- This .signature sanitized for your protection