Laszlo (Laca) Peter wrote: > On Thu, 2008-12-11 at 11:27 -0600, Shawn Walker wrote: > >>>> I'd hope we don't include the spec files or patches or sources in the >>>> package itself. I understand the lofty goal here, but I personally >>>> don't feel it's worth the overhead. >>> Is it such a huge overhead? >> For an individual package? No. In aggregate? Yes. >> >> * overhead of a few actions to every single manifest in that repository > > That would be typically <10 actions.
multiplied by the number of packages that the system is managing. >> * additional indexing overhead to the search engine for each additional item >> >> * possibly polluted search results >> >> * increased resource usage of the depot server for what is essentially >> static content >> >> * overall increased processing time for client and server manifest parsing >> >> * increased publishing time >> >> * processing overhead for clients to filter out this extra content in >> the majority of cases > > This overhead should be similar or adding a few more packages to > the repo, which is what we are planning to do, by the truckloads. Yes, but the extra overhead then is directly justifiable as necessary to serve additional packages. Admittedly, in retrospect, URLs to the sources where this material is maintained could add an equal or lesser amount of overhead in parsing manifests depending on how the information is embedded. The increased publishing overhead, however, is unique to adding these additional resources. It also incurs additional penalties in repository management (time to synchronise the repositories, extra bandwidth and system resources, etc.). >> I don't see how this would be much easier than just having URLs in the >> metadata that are pointed at (and yes, I'm aware we have to host them). > > URLs to what? A copy of each of the files listed above to make sure > we have a snapshot of every source we used for the build? A pointer > to just any version of the spec file won't do. I didn't say it would be just any version; and yes, I would expect a URL pointing to where you could get the corresponding source or spec files. However, as Danek pointed out, this is problematic for packages that are sourced from multiple locations. >> While I understand what you're trying to accomplish, my gut feeling is >> that the depot server is not the right place to host this information. > > I think it is. To simplify, the depot is for hosting files grouped > into packages and nicely versioned so they can be used to construct > consistent images. To host the information for rebuilding these > packages, we need to host files grouped into packages that are > versioned the same way as the binary packages. I still believe it is not the right place to store this information. Quite frankly, I wouldn't want us to be using what resources we have for serving this content instead of the content we really care about: packages. I also think that this content will end up being duplicated, as I would imagine that you would need a copy of all of this content somewhere else anyway (such as a source code control repository). It would seem more logical to me to have pointers to wherever it is that you're already hosting that content instead of duplicating it. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
