On 7/17/05, Glynn Foster <[EMAIL PROTECTED]> wrote: > So I wonder if half the problem that componentized Linux tries to solve > is the fact that so many things fail from a binary compatibility. It's > not clear to me that the added complexity at a package level [and it > seems substantial] is worth the gain. Thoughts?
What I was proposing by mentioning componentized Linux was nothing to do with binary compatability specifically, though that might be an indirect benefit. What I was really getting at is that I would like to see various consolidations of OpenSolaris (ON, JDS, etc.) delivered in a "componentized" format. Such that those wanting to create their own distributions can simply mix and match the components they want to base their distribution from. For example, GroupY decides that their distribution will focus on Live Rescue CD environments, and wants some of what is in ON, but not what is in JDS, and some of what's in another set. The idea being that GroupY to create this new distribution picks the individual "components" or the entire set of what they need/want to create their distribution from. The component sets being called "Core", "JDS", etc. Example: DistributionY of GroupY is comprised of: ON Components XX Components Where ON components would be all of the svr4 packages that are created when building ON, but they would be free to omit some of they chose barring package dependencies. The idea is to basically to make it easier for people wanting to mix and match parts of their distribution or that want to customise their system for a specific set of needs easier. It also makes it easier for 3rd party packaging providers to provide a set of replacements for those components if they so choose. Doing this also encourages compatibility among new distributions because it is more likely they will use the existing components in many cases. Perhaps, I'm dreaming or thinking too much ahead, but I think it's viable. So, really I don't see this as further complicating the packaging process at all. Rather, I just see it as a standardization on package naming, building, and delivery. In my opinion, we could start with ON, and assume that at the beginning the packages as built by the ON system would be the individual "components" of the ON set. > > SchilliX and the Pkgsrc projects are solving the missing base-libraries > > problem by using the SPS-provided ones; but as far as I know, the > > Blastware, JDS/RPM, and Portage projects have not addressed what > > they're going to do about missing base-libraries. > > I'd personally be advocating to work with upstream Solaris to make those > base libraries readily available - and I think there's real value for > other projects to be doing something similar, however stressful it might > be getting that to happen ;) Indeed, at the beginning binary redistribution rights will be sufficient. However, eventual source release is a must for long-term viability. Either that or the necessary information (API specifications) must be available so that an alternative can be implemented. -- Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
