Stephen Hahn wrote:
* Brock Pytlik <[email protected]> [2009-09-30 00:55]:
In short, I believe the right place to do this is actually in the same
place we do indexing. By default, what it should do is remove the
files from the download area which have been removed or changed in
the new packages. Only the imageplan has this knowledge, and I don't
believe there's a sane way to put that approach into the file_manager
b/c it doesn't have access to the plan. Changing the layout will make
emptying the cache each time significantly faster, allowing users to
more easily choose that setting. Of course, we'd also need a "keep
everything setting" and there are probably other settings based on
time/size/the phase of the moon that we may eventually want to
support. All of these are not this bug. I see nothing in the current
design that would prevent an implementation of any of these, if you
do, please give concrete examples. In fact, I see this work making
those steps easier b/c now there's a central location through which
well behaving code will add and remove files, making it easier for
there to be something that has knowledge of the state of the layout
as a whole.
I had thought the layout applied to both client and server, but the
above paragraph is concerned with only client-side management. Is
the layout object only for client-side use?
Thanks
Stephen
No, the layout is for use on both the client and server. Removing files
from the download directory is/(should be) a frequent operation on the
client side, while I anticipate it being a much rarer operation on the
server side. Nonetheless, I believe a similar argument can be made for
the server. It should remove files from its store when a package is
declared obsolete or toxic, again an operation which happens outside the
file_manager. There's also nothing (that I can see) that prevents a time
based file purge on the server, but I think that's at best a very
questionable feature.
In short, the file_manager provides a removal method currently. I
contend that's the extent of its responsibility. Other code is in a much
better position to decide when to remove a file. However, if we decide
we want to add such functionality (such as a time based cache), I don't
see anything in the current setup that would prevent it, and I believe
it actually simplifies a hypothetical implementation substantially over
today's code.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
