On Mon 29 Sep 2008 at 04:46PM, Brock Pytlik wrote:
> image.py
> Line 1538, 1990: I don't see why you're changing this function to take
> progtrack, and then not using it.
Sorry, a failed experiment. I've removed it.
> 1928-1932: I don't really understand why having a user specified
> cache_dir means that we shouldn't clean it up on completion.
I think the common case here is one where the cache is something you're
"borrowing" (for lack of a better word) from somewhere else. You're
installing a zone but borrowing the global zone's cache. In that
case, it seemed to me to be unfriendly to nuke the other image's cache
according to the cleanup policy present in the image on which you're
operating.
Today, we never cleanup the cache anyway, so it's moot, but...
> Also, am I correct that, before, we were adjusting the goal down, now,
> we adjust the downloaded bytes up, when the file is cached on disk?
> Could this lead us to provide some truly strange/amazing/weird results
> for the bytes/sec measure? I'm not saying counting down is necessarily
> the right behavior (though I do kind of like it) but giving what I think
> is incorrect data seems worse. If you provided a way (or filed a bug to
> provide a way) for those bits which are already on disk to not be
> counted in the bytes/sec measure, I don't think I'd have an objection.
Yes, it could lead to very high measures for byte/sec. My feeling
is that eventually we will need to break this up into bytes
downloaded versus bytes filled from cache.
I wanted to avoid invasive changes here until I see how the GUI
folks are doing on their changes to progress tracking.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
