"emerge -v" could use emerge.log to print expected total build time along with the list of packages to be merged (i.e., before any merging begins). Would be useful esp. along with "-p". =============================================================== Today: # emerge -pvuDN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-emulation/emul-linux-x86-baselibs-20121202 [20121028] USE="-development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-db-20121202 [20121028] USE="-development" 0 kB [ebuild R ] mail-client/mutt-1.5.21-r1 USE="berkdb crypt gdbm gnutls idn imap mbox nls ssl -debug -doc -gpg -nntp -pop -qdbm -sasl* -sidebar -smime -smtp* -tokyocabinet" 0 kB [ebuild U ] app-emulation/emul-linux-x86-xlibs-20121202 [20121028] USE="opengl -development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-opengl-20121202-r1 [20121028] USE="-development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-gtklibs-20121202 [20121028] USE="-development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-medialibs-20121202 [20121028] USE="-development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-soundlibs-20121202 [20121028] USE="alsa -development" 0 kB [ebuild U ] app-emulation/emul-linux-x86-sdl-20121202 [20121028] USE="-development" 0 kB Total: 9 packages (8 upgrades, 1 reinstall), Size of downloads: 0 kB =============================================================== Tomorrow?: # emerge -pvuDN world These are the packages that would be merged, in order: (...) Total: 9 packages (8 upgrades, 1 reinstall), Size of downloads: 0 kB, Estimated merge time: 1 min 53 s Reproducible: Always
You mean "expected total build time in Microsoft minutes" ? Cause given ccache/distcc and a few other random factors, that's the best you'd get.
Yes, the factors. What could those be: * distcc: minority of users, I think; I have no experience with it, but if you say it's a problem, it's a problem. * ccache: same story, but is this really such a huge factor? There would surely be an impact when this be turned on/off completely, but how often would one do that? * Different USE flags / pkg version: negligible in my experience, unless you, for some strange reason, literally invert the USE flag settings for a lot of packages. * Sources fetched/absent: only significantly affects a few packages; we've got the parallel fetch now; for most cases no big deal. * FEATURES="test" turned on/off (differently): this is a destroyer, but how many times in your life do you do it and how many packages do you actually emerge with the changed setting? One may have to rotate emerge.log in this case. * Other changes in make.conf: either not serious effect, or changing only rarely/never. * Different amount of CPU time available: implications of this are somewhat hard to predict for me, but would this really be any kind of problem for most cases? * What else? I'm still seeing a good feature. The special cases (features=test on/off, ccache on/off, adding/removing entire CPUs and -j1 <-> -j3, distcc) would be noted in the manpage. Admins would know where the estimation is coming from and they would immediately whether to pay attention to it or not. The important thing is that there would presumably be (considerably?) fewer of the latter kind of admins.
Also consider how easy it would be to implement (the parsing code is there already) and how negligible impact on the output and processing time of emerge it would have. Yet, what a nice little thing to have.
