Oh yeah, and then there is this: http://cooltools.sunsource.net/coolstack/ (Available for Sparc and x86.
On 5/4/07, Brian Gupta <brian.gupta at gmail.com> wrote: > > > 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 > > > > > > >
