Dan Price wrote: > On Mon 15 Dec 2008 at 02:36PM, Shawn Walker wrote: >> One of the things that has bothered me for a while now, is the fact that >> the depot and the repository share the same root directory. >> >> Example: >> >> /export/repo > ... >> I think it would be better for a lot of reasons if this information >> separated. >> >> Any thoughts? > > I'm not sure without knowing the reasons! How much and in what way do > you want to separate things? And how does this intersect with the > "scratch area"? For example, I would not like to see the current
Sorry, I should have been more specific. > contents of /export/repo spread out across the filesystems, into /etc, > /var, and so forth. Keep in mind that changing this will cause a very > large flag day in which the format of the depot directory for all our > depots will have to change simultaneously with the depot code. Or > you'll need to add a versioning scheme and give us a transition period. Right. I definitely wasn't intending to spread things around that much. > So, I guess I'm not upset about the current layout assuming we get > RFEs 2701 and 5211 taken care of. So I'm wondering if this is worth it? > I guess I need those reasons to really have a better sense, it isn't > obvious (yet) to me. Well, specifically: This set of information is fairly static: /export/repo catalog/ (repository catalog data) file/ (repository package content) index/ (repository search data) pkg/ (repository package metadata (manifests)) updatelog/ (repository data; record of changes to catalog) This set of information isn't: /export/repo cfg_cache (depot configuration data; admittedly some of it could be construed as repository specific) feed.xml (depot data) The short version of my concerns was: should we be splitting the data structures so that administrators can manage configuration data, package data, and *publishing* data separately for the purposes of provisioning and resource management? For some reason I had it in my head that the publishing case wouldn't be satisfied by the bug changes you mentioned (scratch area, alternate cfg_cache). Specifically, I'm bothered that an administrator right now can't set a quota for incoming (in-flight) package content because we store those in the same place as we store already published package content. We also store manifests in the trans/ directory instead of some temporary area. So, in short, they have to use ZFS and they would have to split their repo directory into multiple datasets to be able to effectively manage quotas for it. However, if we use the new scratch area for the trans/ directory and we change publication to save newly added files to the trans/ directory until a "close <fmri>" is executed and then rename into place, that would resolve my other concerns. Thanks, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
