Call for testers for yet another ports upgrade program, ports+

[Doug Barton]

On Sat, 28 Jul 2007, Yoshihiro Ota wrote:

> On Fri, 27 Jul 2007 21:49:39 -0700
> Doug Barton <dougb at 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