> > 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, I didn't read the whole discussion, put I did read the post you pointed out. Whether the packages are installed in /opt/csw, /opt/sfw, /usr/sfw, or /usr/gnu, they are still being kept at arms length. I personally don't think picking yet another place to install open source packages is the way to go. I have been told by multiple sources, that the goal is to put everything inside the OS, not off to the corner somewhere. I wholeheartedly agree with this sentiment. I don't think it matters whether it's usr vs opt, it is still isolated. (Just out of curiosity, why /usr/gnu vs /usr/sfw? Aren't we going to be bundling in some BSD licensed code as well? Also why setup yet another?) I want to see if we can agree on what needs to be done. Please respond to my 6 points. I would like to quickly get a ball rolling for those points that we can agree on. Particularly those that require financial resources from Sun. We may want to blast mail the user groups at some point to bounce ideas, and recruit fresh blood. Steve, 1) No need to ship free machines unless you are talking JDS stuff. (Sun does however need to make a pool or shared servers available for these package maintainers to use.) 2) I am willing to contribute as much as I can. So far I am really only committed to one major project. I was planning to pick up more as time passed, but think I will hold off to help with this larger initiative. 3) No JDS tools for package updating. This must be command line first. 3) Keep up the good work. I remember way back when, when you were the only place to get a working gcc build. (Of course back then the first thing I did was download the source and recompile it). :) Everyone, It sounds like we have consensus on merging the various groups into one. (SFW/GNU/CCD). Can we consider that as something that is ready for an ARC proposal? Cheers, Brian 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/companion-discuss/attachments/20070504/3fb296c4/attachment.html>
