On 04/ 1/10 07:09 AM, William Schumann wrote:
On 03/31/10 06:22 PM, Shawn Walker wrote:
On 03/31/10 11:10 AM, William Schumann wrote:
Given the package list currently defaulting for the Automated Installer,
from a local mirror here in Prague, it took almost 14 minutes to finish
the image_create(), plan_install() and to count the sizes at the cost of
186MiB all in <image directory>/var/pkg/. The reported size was 2.8GiB,
which sounds approximately correct. Ran 2 trials on a Ultra 20.
Is there any way to accelerate this process in order to inform the user
sooner about size requirements? Can we avoid the var/pkg/ downloads?
image_create()?
I'm sure it could be, there are a few open RFEs:
385 fast access to size of packages in repo
4134 pkg operations should report operation sizes
With that said, there are a few things that would be helpful to know:
* how long does a second planning operation take after the first
one has completed?
Modified test script to do a second identical planning operation with a
call to the reset() method between. (The reset() method is documented,
but not the requirement for the reset() to be done between planning
operations.) The second took about the same time as the first. The
following is the output from my test script, which is attached:
15450 pydoc for pkg.client.api needs to document reset usage requirement
Also note that all of the manifests that were downloaded to perform
this operation would have been retrieved anyway to perform the actual
install.
The installing user wants to know the requirements to select an
appropriate installation disk. It is impractical for a user to initiate
an install and wait on the order of 10 minutes for this information,
downloading 150MB in the process.
I don't think anyone disagrees, which is why there are several RFEs in
this area (as I mentioned above).
A faster approximation would be more useful than an exact sum. Perhaps a
server-side calculation can be made and cached, taking advantage of the
fact that a small number of different package lists will be
statistically most common. A package depot might be primed to calculate
expected package lists periodically, or when the depot has a major update.
It's been discussed, but it will take time to get it right. Even rough
approximations are difficult when you consider variants and facets which
can significantly alter what the client actually installs.
So far, we haven't had any consumers that actually needed pre-install
size calculation fast, so it hasn't yet been a focus. If this is a
specific need for your project, please add a comment to the RFEs above
so the work can be prioritised accordingly, and include a desired
delivery timeframe.
For now, I'd ask you to live with it if you can, with the hope that it
can be greatly improved soon.
Feel free to file RFEs for API enhancements that would make things
easier for your project or manpage bugs for lack of documentation if
something is unclear.
Until now, we've not had any extensive external API consumers, so your
feedback in this area is greatly valued.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
