On Wed, 2009-09-09 at 14:00 -0700, Brock Pytlik wrote: > Greetings all, > > Last week Shawn and I were talking about why publisher continued to be a > confusing issue for our users. We came to the conclusion that one reason > that users were having problems was that we were conflating concepts in > the items we give a user to manipulate. > > We ended up with the following proposal/attempt to clearly explain our > model. (Note, please don't consider > > There are three distinct entities, publishers, streams, and > repositories. Publishers are the entities who put together > distributions, sign packages, etc... Specifically, they distribute one > or more streams (or trains or whatever term we settle on. dev and > release are two examples of streams for the opensolaris.org publisher.). > Repositories are simply collections of packages, possibly from multiple > publishers and multiple streams from those publishers. > > Right now, what we're really giving users the ability to maipulate is > repos. Sure, the command is called "set-publisher" but we assign a > specific url which corresponds to a specific respository. I don't think > it's surprising that this confuses users. Further, to change from > release to dev (for example) we tell them to use set-publisher to change > the url of the publisher. > > What we suggest instead is that our UI reflect our model, rather than > conflating our abstractions. We suggest that a publisher (optionally) > have a default stream, and that each stream (optionally) have at least > one default or known repository which holds (at least) all packages in > that stream of that publisher. So, a user starting with an empty image > would do "pkg set-publisher opensolaris.org http://pkg.opensolaris.org"; > (for example) and the image would be set up to use the release stream of > pkg.opensolaris.org and would know about one repository (say > http://pkg.opensolaris.org/repo). > > After a while, the user decides that they want access to the packages in > contrib. I assert (for the purposes of this example) that contrib would > be published by opensolaris.org (ie, they would sign the manifests), so > the user would do "pkg add-stream opensolaris.org contrib". That would > allow them to install packages from contrib (since either the default > repo for contrib would now be known to them or the contrib stream > packages in pkg.opensolaris.org/repo would now be available depending on > how we decided to organize our repos). Part of what "pkg add-stream" > would do is ensure that the contrib stream is not known to be > incompatible with the streams currently active on the system. > > Let's say that Sun (as opposed to opensolaris.org) publishes the > packages currently in Extras. The user would add Sun as a publisher, > then add the Extra stream. > > If the user tried to add the release stream from opensolaris.org while > the dev stream was active, pkg would error and inform the user that > those two streams were incompatible according to the publisher. The > publisher could define those incompatibilities both for streams it > produces and the streams of other publishers. This is how the support > stream would be handled since it (at least right now) seems to be > published by Sun, rather than opensolaris.org. While within publisher > incompatibilities might be common, between publisher ones should be rare. > > Streams are comprised of packages, and other streams. For example, once > we've broken up our consolidations to some extent so that entire no > longer exists, we imagine opensolaris.org delivering a dev stream which > corresponds to what dev is today. The dev stream though will consist of > multiple streams, dev-on, dev-sfw, dev-gnome. Similarly, the release > stream will consist of multiple streams, rel-on, rel-sfw, rel-gnome, > etc... The dev-on stream would have an exclude dependency on the rel-on > stream (and the other way around). This allows users to chose to run the > dev-on kernel, but the release gnome bits, within the contraints imposed > by specific package dependencies. > > The on-disk package of the future would include the information that > would otherwise be retrieved from the publisher upon installation. > > That seems to cover most things. We're suggesting that streams live in > the package namespace, like publishers do. > > We also have some ideas of what the GUI interaction should look like, > but we'll save that for another proposal if we decide that what we've > laid out seems like a reasonable way to go. > > Thanks, > Shawn and Brock > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Great! -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
