Hello Liane, IMHO, there are no obvious issues with your points. The key difficulty up to now is getting everyone to agree on a central repository.
The problem is social, not technical. If we could just all agree, and get something rolling, that would be ideal. :) On 5/3/06, lianep at eng.sun.com <lianep at eng.sun.com> wrote: > > Dennis, sorry for the delay in response (I was taking a hiatus from > mailing lists for a bit). I think this is an important discussion to have, > and thank you for kicking it off. > > "Dennis Clarke" writes: > > I want to take the lead here and bring a topic to the table that needs > > to > > be focused and precise. What I would like to discuss is how we may create > > a set of libraries that are open source. > > You also said in another thread: > > > So the dream is still a common set of libs that are up to date and able > > to be compiled and dropped ( repeatedly and consistently ) into some > > LIBPATH somewhere on Solaris 8 and upwards. > > Cool. I'm in complete agreement with your dream. Indeed, I consider this > to be a fundamental area of potential collaboration. > > Generally, one of the biggest points of contention seems to be about the > environment at compile time: i.e. built on S8 versus built on Nevada. > If we could all share one source base and allow different distributions > (where I count Blastwave, Sun, and many others as distribution owners) to > compile according to their requirements, we'd be in great shape. Then > we don't need to argue about who builds on what release. It's up to the > individual typing make. :) > > Sharing a source repository that we could all build according to our > own whims would give everyone the biggest value for a contributor's > time, as we could all share the work that a contributor did to get a > piece of OSS building. > > To that end, here's the list of requirements that I've come up with > for such a source repository. Note that there's nothing in the > requirement set that would restrict the proposal to libraries at this > point. It's not organized in any particular order, so apologies for > lack of obvious flow or duplication. > > - All source in the tree must work together. If updating a component > that other parts of the tree depend on, should test the dependents > before integrating the update. > > - Individual components in the tree must be individually buildable > for distributions who want to cherry pick components and for ease > of development for contributors. Restrictions on build environment > (e.g. must have current tree installed at a well-known location) are > acceptable. > > - Must build SystemV packages. We could/should talk about how to enhance > the structure to allow component or distribution owners to > contribute support for other package types (e.g. SPS, etc.), but > components must at least support a SystemV package build > environment. > > - Must support components which are targettable during build time > to a specific release. That is, should be able to specify that > gnome libraries are built and linked against *only* on on old > releases which don't deliver them via a separate consolidation. > > Put a different way, components shouldn't be duplicated for a > single release branch among multiple consolidations. But, that > doesn't mean that can't be included in the source repository. > > (What build environment is required for initial integration may > be up for debate at a later point.) > > - Components built on multiple releases should be able to take advantage > of better/newer/more performant features through build time choices. > > - Source code of component must be included in the tree. No binary > objects, as they're unauditable. > > - Divergence from the main trunk of the OSS component is strongly > discouraged. Component owners are encouraged to establish a > relationship with the upstream component providers and contribute > back OpenSolaris portability changes directly. Where divergence > is required because the upstream component can't/won't take the > changes back, the differences must be easily auditable. > > - Install location for the built packages should be settable at build > time. > > - For OpenSolaris releases that support Zones, packages should work > in Zones. > > - Contributions must be reviewed. (The mechanics of this should be > debated at a later point.) > > - Build environment requirements must be clearly documented so that > builds are 100% repeatable. (Different releases may have different > build environments, obviously.) > > - Only Open Source Software may be included. > > So, what points do people disagree with? Which ones need clarification > (I know my writeups suck on a number of them)? What points would be > missing in order to offer a solution that could easily be built on by > people who want to offer binary packages? Is the entire idea crazy and > unworkable (if so why)? > > (I haven't run these ideas past anyone else at Sun, so please don't > take my proposal as anything except for a set of discussion points by > an individual engineer. I don't speak for anyone except myself in this > mail.) > > liane > -- > Liane Praza, Solaris Kernel Development > liane.praza at sun.com - http://blogs.sun.com/lianep > > > _______________________________________________ > companion-discuss mailing list > companion-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/companion-discuss > -- Regards, Jeremy
