Darren J Moffat writes:
> John Plocher wrote:
> > For things like cat, ls, ..., there is no real reason to
> > continually recompile and redeliver them on a nightly or
> > even bi-weekly basis - they don't change that often. What
> > would happen if they were built and pushed into a repo only
> > when they changed?
>
> The major down side of that is that since the source almost never
> changes they wouldn't get the benefit of all the generic changes. For
> example ON related linker changes for direct binding, non executable
> stack, and in the past largefile support. On the other hand tools like
> ls actually did get quite a big set of changes recently and this might
> not have been as easy to do if they were in a consolidation other than ON.
I don't see that as a substantial down side. We already have that
disconnect with other consolidations -- many of which deliver
substantial components that could benefit from those changes.
Instead of folding everything into ON in order to get the "goodness"
in that gate, I think it'd be better to find ways to spread that
goodness around so that everyone can make use of it.
That might mean mechanical changes (more common build environment
alignment and tools), it might mean more documentation, and it might
mean more contact between the gatekeepers of the various
consolidations. Likely, it means all of those things.
> Before we do refactoring of stuff that *is* OpenSolaris, rather than
> upstream FOSS, out of ON we need to be sure what the goal is and what
> won't happen to those things if they move out of ON. Some things rot in
> ON as it is I'm concerned that if the are moved elsewhere the will rot
> even further by not being able to take advantage of the "consolidation
> wide" changes that happen quite frequently in ON.
The goals I see:
- Lower overhead: not rebuilding things that don't need to be
rebuilt and not copying things around that nobody really needs.
- Allowing for the per-package versioning that the OpenSolaris
distribution expects, rather than building everything as one
indistiguishable lump (and trying to rely on error-prone binary
compares).
- Forcing more projects to rely on documented and stable interfaces,
which will both help produce better underlying facilities and
produce more maintainable layered projects.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
