Date: Sat, 28 Jul 2007 21:12:51 -0700 (PDT) From: Doug Barton <dougb@FreeBSD.org> To: Yoshihiro Ota <ota@j.email.ne.jp> Cc: freebsd-ports@freebsd.org Subject: Re: Call for testers for yet another ports upgrade program, ports+ Message-ID: <20070728210114.B16750@qbhto.arg> In-Reply-To: <20070728210037.5ea54891.ota@j.email.ne.jp> References: <20070726011654.cec378be.ota@j.email.ne.jp> <46A866BE.1000407@u.washington.edu> <20070726233610.e536c2e2.ota@j.email.ne.jp> <46A9A56E.5080608@FreeBSD.org> <20070727215923.a5c3c2aa.ota@j.email.ne.jp> <46AACAE3.2060401@FreeBSD.org> <20070728210037.5ea54891.ota@j.email.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 28 Jul 2007, Yoshihiro Ota wrote:
> On Fri, 27 Jul 2007 21:49:39 -0700
> Doug Barton <dougb@FreeBSD.org> wrote:
>
>> Hiro,
>>
>> I'm happy to respond to you, but first I'd like to make clear that I'm
>> not trying to talk you out of anything. If there is a better way to
>> manage ports, or even just a different approach, I'm all for it. I
>> don't think portmaster is a "one size fits all" tool, and I'm not
>> trying to make it one.
>
> Doug,
>
> The same goes here.
Great! I'm glad we understand each other. :)
> I see. When I just started ports+, I also attempted doing like that.
> However, when I looked into bsd.port.mk, I found that the ports system
> uses the INDEX file for pretty-print-run-depends-list. Then, I decided
> to read the INDEX file myself for 1. it's faster to parse it myself,
> 2. more information is available, and 3. prevent generating processes.
That's a very reasonable conclusion. FWIW, the primary reason I chose to
ignore the INDEX is all of the problem reports on the -ports list from
portupgrade users about something breaking because of problematic INDEX
generation. Being able to use 'make fetchindex' has solved a lot of those,
but the other issues that arose as I studied further are the problems of
dependencies changing based on what is installed already on a system, and
what options the user chooses in the 'make config' stage. There is also of
course the problem of the INDEX sometimes being just a little bit behind the
ports tree. That's not a criticism, just a fact of how things work.
Having the users generate their own INDEX solves some of these issues, but
it introduces some new problems. The first is obviously the time it takes to
generate (when you compare that to the time portmaster takes to recurse the
dependencies itself I think portmaster comes out ahead), and the second is
that the user has to maintain a full ports tree even if they will never use
a lot of those ports. I know I have a pretty big refuse file for c[v]sup,
and I was not interested in the additional bandwidth and storage that a full
tree entails.
>> The benefit comes when you actually start building stuff and because
>> all the information about the up to date ports is cached, it won't
>> have to be reevaluated.
>
> What do you mean by cached? Is it file-cache by VM? Is it something
> the ports system do? Or is it something else?
Portmaster starts a parent process to upgrade the port(s) specified on the
command line. It then spawns children as needed to handle the upgrades of
individual ports. Each child process inherits a set of variables that
describe what is already known about the "up-to-date-ness" of the ports that
have already been examined. The child adds whatever information it
discovers and feeds that back to the parent. Lather rinse, repeat.
hth,
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070728210114.B16750>