On Tue, May 26, 2009 at 10:43:16PM +0200, I. Szczesniak wrote: > On 5/26/09, Garrett D'Amore <gdamore at sun.com> wrote: > > I. Szczesniak wrote: > > > Is this the only justification? Bits delivered via SFW commonly have > > > substandard quality and are very poorly integrated. I fear that > > > putting a critical system component such as perl into SFW will affect > > > the quality of Opensolaris as whole piece. > > > > Can you cite any evidence of this? I think a lot of excellent software is > > delivered via SFW. > > Excellent software which is poorly integrated into Solaris. > > Evidence 1: Configurations changes in random intervals, i.e. > postgresql using select() instead of poll() and MAP_ANON depending on > system load of the build machine. postgresql tcl is broken in some > SXDE/SXCE releases because it picks the wrong libraries randomly, too.
PostgreSQL was never in ON. Delivery through SFW did not result in a downgrade. What you describe sounds like a bug, and it's not remotely clear how the choice of consolidation could have led to it. > Evidence 2: Software in SFW uses suboptimal compiler flags. Software > delivered via SFW uses only SFW default flags or the flags discovered > by autoconf. Some bits are even delivered without the optimizer > enabled. > Roland Mainz said he'll take a look but never responded to that subject. This too would be a bug. > Evidence 3: API stability. Shall we discuss the random disappearance > and appearance of features here? Its rarely noticed that adding > software to the build machines silently enables new or changes > existing features in the SFW software. The SFW consolidation, like the ON consolidation, adheres to the same ARC best practices with respect to interface stability taxonomy and release bindings. > perl 5.8 in ONNV was added by someone who knew the shortcomings of > perl's automated configuration and wrote his own Makfiles to avoid > them. Putting perl into SFW will those shortcomings appear again in > the system perl installation. I doubt that. I suspect you're speculating here. I would speculate that Perl was integrated into ON earlier because it was the consolidation that the engineer who did the integration was most familiar with, or because the Perl integration into ON pre-dates the SFW consolidation. Having put FOSS into both consolidations I can assure you that the process of adapting the build process of a FOSS item to the ON build structure is complicated, error prone, and requires more maintenance; whereas the process of adapting the build process of a FOSS item to the SFW build is straightforward. Nico --
