Date: Tue, 22 Aug 2006 23:30:09 -0700 From: Doug Barton <dougb@FreeBSD.org> To: "Michael W. Lucas" <mwlucas@blackhelicopters.org> Cc: ports@freebsd.org Subject: Re: "the best" port update tool Message-ID: <44EBF5F1.4050802@FreeBSD.org> In-Reply-To: <20060822010628.GA96258@bewilderbeast.blackhelicopters.org> References: <20060822010628.GA96258@bewilderbeast.blackhelicopters.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44EBF5F1.4050802>