Would it be possible to consolidate these conversations on a single list? ports-discuss is as good a place as any...
On 5/4/07, Eric Boutilier <Eric.Boutilier at sun.com> wrote: > > 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 > > > _______________________________________________ > ports-discuss mailing list > ports-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/ports-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/companion-discuss/attachments/20070504/c6a0b4c3/attachment.html>
