Danek Duvall wrote: > On Wed, Jan 14, 2009 at 04:18:08PM -0600, Shawn Walker wrote: > >> Staged Publishing >> ================= >> Staged publishing being defined as the ability to publish packages to a >> repository without packages from a given publishing "session" being >> added to the catalog until explicitly instructed. >> >> Right now, if clients retrieve a new catalog from a repository as a new >> OpenSolaris release is being published, they may inadvertently attempt >> to upgrade to a release that hasn't yet had all of its packages >> published causing errors. > > This makes it sound like we're publishing directly to the servers that > people are using as their authorities, which is not the case. If it were,
For the public servers yes. However, I have been told it is the case internally, though I personally have not verified that. > there would be a far better way of preventing the problem -- don't publish > entire until the very end, and then no one would be able to upgrade to the > new packages sitting on the server (or, once we have the INCOMPLETE state > implemented, wouldn't even be able to see them). If that change hasn't already been made in the importer, I'll open a bug. > The problem is more subtle than that, and is probably covered by your > "Staged Deployment" section. I'm not sure that "Staged Publishing" solves > a real problem. > > Or am I completely misunderstanding what you're talking about? Staged publishing is helpful in scenarios other than the "entire" case, and I should have noted that. For example, publishing a new package to the repository that requires a new version of other packages not published yet. Since, currently, a packaging client will try to install the latest version of a particular package, and would fail because the newer dependencies were not available. I admit the "INCOMPLETE" would suffice here. The one benefit that I could see in "staged" publishing is to make it easy to determine catalog snapshot boundaries for "staged" deployment. >> Staged Deployment >> ================= >> Staged deployment being defined as the ability to serve multiple >> versions of the catalog. This should have said: ...being defined as the ability to serve a specific catalog snapshot. >> This would require changing the depot server to allow the administrator >> to provide a date representative of a catalog snapshot >> (repo_dir/catalogs/ISO8601DATE/) to serve instead of serving the current >> catalog data (repo_dir/catalog/). >> >> Storing the current catalog in repo_dir/catalog allows backwards >> compatibility with our existing depot versions allowing staged >> deployment/publishing catalog support to simply be ignored by older >> depot versions. > > We can require a depot upgrade, I think. There is a major flaw here that just came to mind; notably, that the catalog, index, and updatelog directory all have to be included as part of this. In other words, if I'm serving a particular version of a catalog, then I also have to serve a corresponding version of the search index and updatelog. I need to think on this some more and come back with a revised proposal. Thanks, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
