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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/companion-discuss/attachments/20070504/03b2d3ef/attachment.html>
