portupgrade-devel: 2 feature requests

[Doug Barton]

I'm going to respond to these from the portmaster perspective to try
and give some additional context. No criticism of portupgrade is
intended, since I've said many times that they are not completely
overlapping in feature sets.

I'm also responding since I think these are interesting questions and
I've put a lot of thought into my solutions for them. :)

Aryeh M. Friedman wrote:
> How hard would it be to add the following to portupgrade-devel:
> 
> 1. Progress report for -a builds (i.e. after and/or at the start of a
> port build it says how many ports are left to be processed)

That probably wouldn't be too hard to add, but it wouldn't really tell
you very much since 1 firefox build will take longer than just about
any 10 other ports.

> 2. Interruptible -a builds (i.e. portupgrade -af will restart from where
> it was last interrupted [perhaps with an additional flag?])

Portmaster has this feature, you add the -R flag along with -f (or
-r). (Note, not all command line options mean the same thing for both
tools. Look at the man pages.) You can also use the -C flag to avoid
deleting what you've already built for ports in progress.

> Also two behaviours that make no sense to me:
> 
> 1. When doing portinstall and/or portupgrade -af on a large set
> dependant ports (such as xorg) the default options get built *BEFORE*
> the option screen is displayed.   For example when doing xorg-drivers
> nv, ati/radeon/i810 are built before it asks you what drivers to build.

Portmaster runs through all the options dialogs first (and downloads
new distfiles in the background), then starts the building process.

> 2. When doing a portupgrade -af the order of builds seems to not follow
> any pattern interms of depend relationships (topo sort?)

If you're going to rebuild them all anyway one could make the argument
that the order of where you start doesn't matter, as long as each port
is rebuilt "depth first." I.e., that you update all of its
dependencies (and all of their dependencies, etc.) first.

However, portmaster splits the ports into categories, and rebuilds the
ones with the least (or zero) dependencies first so you're going
(roughly) "up" the tree as you (re)build stuff. This sometimes results
in recursion down the dependency tree anyways since you have to start
somewhere, and portmaster runs through the categories alphabetically.
But since it does the same depth first traversal here that it does for
any other build, this doesn't matter. It also caches the information
about what ports are already up to date (or already built in a
previous run for -R) so you don't have to duplicate any effort.


hth,

Doug

-- 

    This .signature sanitized for your protection