Date: Thu, 14 Feb 2008 13:26:38 -0500 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org, sem@FreeBSD.org Subject: Re: portupgrade-devel: 2 feature requests Message-ID: <47B487DE.5090609@gmail.com> In-Reply-To: <47B481E5.3010000@FreeBSD.org> References: <47B47052.8010404@gmail.com> <47B481E5.3010000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Doug Barton wrote:
| 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.
The idea is more along the lines of knowing how far you are away from
completing the whole build (should I interrupt it and restart it from
scratch later or just let it run if I need to free up the system
resources used for building [portupgrade at least doesn't do anything to
make it so you can run other heavy processes like your own programming
or mplayer while doing a portupgrade {namely I would like to keep long
run builds truelly in the background... and renicing only renices
portupgrade not the forked makes}]).
|
|> 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.
This means you need to keep track of what top level ports you have
installed in your head or in notes somewhere. Also in reading the man
page for portupgrade I do not see how -C does what you say it does "
-C --force-config Run ``make config'' before everything for
all tasks."
|
|> 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.
Does it also check for conflicting options at that time?
|
|> 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.
Thats what I was saying as far I can tell portupgrade doesn't respect
depend order even.
|
| 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.
|
|
That caching is what I was asking about I think in the second feature
request but also make it apply to -af.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHtIfek8GFzCrQm4ARAtBLAKDOApxxBfymGP/wQZ123eBW3droPACglPLW
Ipwf8c0uacvJ2X1FXPjP+HE=
=FTa2
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B487DE.5090609>