as it stands right now, emerge.log provides an easy way to check the amount of packages left on the queue, and with a bit of data mining, what packages have been installed in the current session. How difficult would it be to implement a way of storing a copy of the queue in a flat file (one ebuild per line), which is updated when the next ebuild in the queue starts being processed? EXAMPLE: app-example/a requires app-example/b app-example/b requires app-example/c app-example/c has no dependencies the queue (in order) for `emerge app-example/a` would be app-example/c -> app-example/b -> app-example/a and once emerge figures that out, it would write to a file (IE: "/var/log/emerge-queue_2007-11-16_16-27-00.log" <- dated and timed at start of emerge operation to allow for multiple ongoing emerge operations) "app-example/c app-example/b app-example/a" and when app-example/c is emerged and app-example/b starts being processed, the file would be updated to "app-example/b app-example/a" and the process would continue until the emerge process is complete for all packages, at which point the queue file would be deleted, since all the information on it will be in emerge.log This would allow the user or a third-party application read-only access to the queue to (a) see what packages are going to be installed, (b) how many packages are left in the queue (line count of file), and (c) do so with standard tools such as less, wc, and grep--and not having to know Python.
(In reply to comment #0) > How difficult would it be to implement a way of storing a copy of the queue in > a flat file (one ebuild per line), which is updated when the next ebuild in the > queue starts being processed? It's not difficult but it's also not very elegant. At the moment, you can use the output of `emerge -p --resume` to see a list of ebuilds that are currently scheduled. In the future I plan to create a more general job control interface that will allow you to get that information an more. There will be support for parallel builds, so a list of scheduled builds will show an estimated build order that may vary if parallel builds are enabled.
BTW: Current versions of portage write the mtimedb in JSON format: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7c4c48d9a4344a6f1c9859ae178ed78408ba2777
