Brian, Discussions around this general topic interest me a great deal, and this iteration of it adds _some_ new context I think. However the best way for me to give my perspective here is to point to the previous iteration of this topic that Mike Kupfer just pointed to. That is, my views remain pretty much the same. In particular, as summed up mostly by this post:
http://thread.gmane.org/gmane.os.solaris.opensolaris.general/18953/focus=19022 But also by other parts of that discussion. Eric On Fri, 4 May 2007, Brian Gupta wrote: > I think the overall issue needs to be broken down into a number of parallel > initiatives/projects: > > 1) There is no common packaging system that meets the needs of the community > in use today. We need to come up with one that supports dependencies, > updates, and network repositories. (Mirrors are welcome). All parts of > Solaris will need to be repackaged with this standard. SFW will be of > supported of course, as will unsupported packages. All packages will closely > coordinate with Project managers who are OpenSolaris members. Also there is > a question as to whether SYSV Package tools can be open sourced. Without > that we can't do much with the existing tools, and might have to seriously > start thinking about a completely new packaging system. (Initially the GNU > stuff would all need to be repackaged, but the end goal would be to have all > of Solaris packaged this way.) (We need a multi community project to come > up with a distributed packaging and build system.) Note to self - It should > support self building source packages. > > 2) There is no common repository for packages. This needs to be addressed. > There should be a common repository for OS packages, including the kernel, > as well SFW packages, and all the third party and community maintained > packages. (Supported or unsupported, this is where people go to get Solaris > packages). Sun needs to step up to the plate for this one. > > 3) If Sun seriously expects third party GNU maintainers to build Solaris > packages, they need to provide the build environments, or it just won't > happen. Again, Sun really needs to step up. > > 4) We need to figure out how SFW packages are going to be maintained. I have > heard to conflicting visions, both from within Sun. One vision says, stick > to a specific version of an Open Source tool, and then just back patch that > selfsame version until the next named release of Solaris. The other vision > says that if the mainline opensource app has a few verion increments and > they warrant updating the SFW package, go ahead and grab the new version and > recompile it. We really need to wrap our hands around this, as there is a > serious mental divide here. (I actually lean towards a mixed method myself). > (This should be hashed out in its own thread, and then a formal should be > proposed to the powers that be.) > > 5) For now, we have to rely on Sun employees, OpenSolaris members and the > maintainers from coolwave and sunfreeware.com as our build masters. By > consolidating our resources, we should be able to handle more packages. The > ideal to become evangelists is a good one, but it's premature. It can't > really take off until 1-3 are worked out. I can find GNU maintainers that > want to contribute, but they want to just configure compile and bundle their > package. They aren't familiar with Solaris, we shouldn't force them to > become Solaris SAs. Let their contribution be the most efficient it can. > The more non package related work we ask them to do the less likely they wil > be to get involved. This could be a a future project. I envision that the > majority of our package maintainers, will continue to want to maintain > packages. There will however, be a new role that package maintainers can opt > to take on. That role is integration project manager. That job is to > coordinate builds that are being done by other people. This would include > unfocused hands that want to help out on either a temporary or ongoing > basis, as well as coordinating with authors and GNU package maintainers, > that are willing to take on Sun Package maintenance. > > 6) This is really part of one, but it controversial and will need top level > buy in. Whether or not package x is supported or unsupported, it should be > installed in the same place. e.g - /usr/bin/x > > Ideally once this is all in place, one could run "spm-get upgrade-all" and > after some time, the system would be running the latest version of > OpenSolaris. > > -Brian >
