On Thu 01 Oct 2009 at 08:28PM, Shawn Walker wrote:
> Dan Price wrote:
> >On Mon 28 Sep 2009 at 03:01PM, Shawn Walker wrote:
> >>>> trans/
> >>>"trans" on the client?
> >>That shouldn't be there; thanks.
> >
> >I spent some time on this last night, but ultimately was a little
> >confused. Any chance you could publish an updated version which
> >includes the changes made in the past week?
>
> I did; the only recent change was the omission of trans/ from the
> client. But I've reposted with that one change below.
Ok, sorry, I thought you were planning to lift publishers up a level.
>
> >One specific point of confusion: what is this part about?
> >
> > pkg_cache/
> > <stem>/
> > <uri-encoded-version>.<cache_name> (manifest cache file)
> >
> >I wasn't clear what the function of pkg_cache/ was, in comparison
> >with 'pkg/' on the server, or what "cache_name" meant. Sorry if
> >I am just horribly confused.
>
> So pkg_cache is for the files that CachedManifest writes out for a
> package. They're not meant to be retrieved by a client, so separating
> them out from the normal manifests makes it that much easier to run a
> depot out of /var/pkg.
>
> <cache_name> is the name the CachedManifest class uses for each of the
> cache files, such as: depend, dir, dircache, file, license, link, and set.
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?
> ==============================
> Proposed Client Storage Scheme
> ==============================
> <IMG_ROOT>/
> cert/
> history/
> index/
> pm_cache/
> state/
> publisher/
> <publisher>/
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.
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss