On Tue, Feb 06, 2007 at 03:31:35PM -0500, Glenn Fowler wrote: > "... offer autoconfigure if that's what their customers want ..." > > what is the context for this statement? > > customers want code that builds and runs without intervention > they want it to run on all of their systems from windows through unix through > MVS > they want it to behave the same modulo resources on all of their systems
OS omnivores and DIYers want that, certainly. Customers of distributions want (and use distributions because of a perceived greater ability to provide) stable, working, reliable software. At best, the two objectives are orthogonal. > "opensolaris lets you write beautiful code" > > ... that most likely would be stuck in opensolaris or would > require configuration for other systems, *including posix* Since no purely-POSIX system exists on the market, the latter seems like an academic concern. In any case, I have nothing against people who aren't using OpenSolaris-based operating systems, but they're not the people I'm writing code for. They're welcome to use the code under the terms of the license(s), but the OpenSolaris engineering community is under no obligation to sacrifice quality to help them do so. When we can, we help third-party porting teams, and we should. It's the neighbourly thing to do. But that doesn't mean we should structure our own codebase around non-OpenSolaris users' ability to port quickly. > are any GNU components in ON? perl? emacs? None that comes to mind (certainly none that use autoconf). Yes, and it has its own ON-specific makefiles. No. > suppose that entry into ON requires removal of all iffe/configure > who takes the responsibility for: > (1) ripping out iffe/configure for each package update The project team or engineer(s) who do the updates. In most cases, it's not so much a matter of ripping out as of understanding what's changed, updating the relevant source files, and adding a few lines to makefiles to account for additions. Redoing the integration each time seems unnecessarily time-consuming. > (2) validating that the package+configure is the same as package-configure I'm not sure I understand what you mean here. Proper functionality ought to be measured against a set of regression tests with known-*correct* output, not the output of an arbitrary binary. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
