Dan Price wrote:
On Thu 01 Oct 2009 at 08:28PM, Shawn Walker wrote:
>> ...
I see, so... I suppose I thought that a client was going to have, nested
within it, essentially, a server layout. In this proposal, the two are
somewhat more intermingled than I might prefer. Could we do:
client:
==============================
Proposed Server Storage Scheme
==============================
<REPO_ROOT>/
catalog/
index/
publisher/
<publisher>/
file/
pkg/
<stem>/
<manifest-named-after-uri-encoded-version>
trans/
<IMG_ROOT>
repo/
catalog/
index/
publisher/
<publisher>/
file/
pkg/
<stem>/
<manifest-named-after-uri-encoded-version>
trans/
client_publisherdata/ [or some other name]
<publisher>/
<client specific publisher stuff>
index/
ssl/ <or cert?>
history/
pm_cache/
state/
Would that work?
s/client_publisherdata/publisher/, but otherwise, I'd be reasonably
happy with it. (I'm trying to avoid long names.) Although, I'm not
thrilled about another level of nesting, but I can see why you'd value
the layout.
I'm also assuming this means that I would drop the pkg_cache/ directory
then from /var/pkg/publisher, and just have
/var/pkg/publisher/pkg/<stem> structures to store the CachedManifest and
license files.
The one major advantage I could see of having the extra level of nesting
would be that you could trivially re-map the client to an actual
repository (on a file system) and get invisible caching.
I guess what I was hoping was that everything "server" would really be a
subdirectory within the client, so that if you wanted to extract one
from the other it would be easy. Maybe that's a non-goal.
It wasn't one of the goals I was attempting to achieve, but whether or
not it should be is something I'll leave for others to comment on. I
know that Stephen would like repoA + repoB to be an easy operation if
that helps any.
Finally, I'll assume that by "extraction", you mean "copy"; since
removing the entire directory would be bad for the client (mainly the
package manifests).
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
