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

[Yoshihiro Ota]

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.  With my approach, if I can handle let's say 90%
of cases, that's fair enough.  But, let it do as FAST as possible.
If one claims he has 32 CPU or 32 cores, let him use all.
And let other tools like portupgrade and portmaster handle difficult
cases.  They are better for intarctive use.  For instance,
I can never do --recursive option in portupgrade in ports+.
It is something impossible for a 'make' utiltiy to do.


> Yoshihiro Ota wrote:
> > On Fri, 27 Jul 2007 00:57:34 -0700
> > Doug Barton <dougb at FreeBSD.org> wrote:
> > 
> >> Yoshihiro Ota wrote:
> >>

> > Could you tell me a bit more or point to a source if already
> > written on how portmaster works.
> 
> The man page has a good overview, I have documented it relatively
> thoroughly, and I keep it up to date. You can either install the port,
> or do:

I will do so.

> >>> However, "portmaster -a -n" wasn't not fast, neither. 
> 
> I should probably point out that this is the worst case scenario,
> since by definition portmaster -a has to evaluate each installed port.
>  The vast majority of the time spent doing that though is in 'make -V
> PORTVERSION'.

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.

> 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?

> I think it's useful and healthy to discuss where both the various
> tools, and the infrastructure can be improved.

Sure.  I took what portupgrade is doing to upgrade ports to make ports+.
I.e, saving dynamic libraries, and so on.  When you mention something
like 'make -V PORTVERSION', it gives a good idea how to get something
out of the port system.

It just occurred that as the ports system generates INDEX and ports+
uses it to write out Makefiles, the ports system might be able to
write Makefiles for upgrading, too.

Hiro