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
