On Tue, Jun 20, 2006 at 10:09:27AM -0700, Keith M Wesolowski wrote: > Using a per-component proto area is helpful in solving this last problem, but > it has two major drawbacks as well: it makes it effectively impossible to > manage intra-consolidation, inter-component flag days (because you can't > build dependents against their current dependencies), and it requires > additional work to deliver packages consisting of parts or all of multiple > components (such as SUNWsfwhea, unfortunate though that
Both good points. > And here's where we really come to the crux of the philosophical > differences between JDS and the rest of the Solaris organisation, > especially but not only ON. The procedure you're describing is one > which asserts that "upstream is assumed to be correct" and if in > doubt, the effects of using the autotools-based build system are > assumed to be desirable. That's perfect for compiling what the GPL so > eloquently terms "mere aggregations" of software, but it's dead wrong > for building a tightly integrated polished product. Isn't it better to fix upstream where possible than continue to apply fixups until the end of time? Sure this might not always be possible, or feasible, but it has to be better than not trying. > As a concrete point, why should the default be to include all new > files built by a component's makefiles? Shouldn't we at least know > what we're shipping to customers? Any upgrade needs careful examination of what's delivered, either way. > And if we know what we're shipping, > is it so much to ask that we explicitly specify it (in packaging > files, if not in install-sfw or equivalent) I think explicitly specifying things is a reasonable burden. The problem with not using "make install" is it's so error-prone: to integrate an upgrade, the developer has to (currently) do something like: 1) examine all the package's build infrastructure carefully to ensure the files being picked out by install-sfw (or whatever) are still the right ones, and that none are missing. 2) examine the hand-crafted install script to make sure everything is in its right place. In particular, that any changes we need are still both correct and complete, and that any further changes in what gets installed (perhaps by carefully comparing against the 'real' make install) are picked up. 3) verify both of the above against the packaging With a "make install" based approach, it seems a lot easier, and a lot less error-prone, to verify that any changes we need to make are still valid, and that we're correctly picking up what upstream ships; this remains true (IMO) even if pkgdefs is hand-crafted. regards, john
