* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-23 11:31]: > On Fri, 2007-02-23 at 10:59 -0800, Stephen Hahn wrote: > > > > That is, why not just merge CCD, SFE, and SFW into a "freeware" > > > > consolidation that delivers appropriately to /usr, /usr/gnu, and > > > > elsewhere, and allow multiple build approaches? > > > > > > Knowing both build approaches, I simply don't see how you can > > > merge 2 vastly different build systems into a coherent system. > > > > Umm, make drives feature-level build dependencies, pkgtool builds > > individual packages, both toolsets install their packages (and test > > package dependencies) against an alternate root? > > Building against an alternate root has some serious disadvantages: > - you can't be really sure that the build doesn't pick up "stuff" > from the real root > - you need to force autotools to work in a way they weren't designed > to and it's a source of much pain and hacking There are multiple mechanisms one can use here to control the reach of your build; other (non-Solaris) build systems have managed, for instance, to use chroot(2) to control the contamination of the built objects by local state. I know JDS use of pkgbuild also allows this, so I don't think it's a stretch to consider modifications to force the SFW build to be chrooted as well.
There are other approaches one could take here: contributors should build on NAT'd zones or Xen images, or whatever. The point is that a build process that is unknowably sensitive to the native install image is held to be insufficiently controlled. Others have been more eloquent to this point than I. The main point is that someone has to just pick a mechanism and articulate its costs. > > That is, SFW gives up the notion of separated proto area and package > > build phases, and pkgtool doesn't use its .spec dependency evaluation > > as part of the build. SFW and pkgtool policies on pulling versus > > keeping a static copy of upstream sources will have to be reconciled; > > there are a couple of choices here. > > > > I'm sure there are other issues, but I don't think it's unprecedented > > complexity by any means. > > Right, it can be done. I guess I just don't really see the > point. What would be the advantage of this compared to building > the 2 sets of packages separately, as if they were in a different > consolidation, even if they are delivered together? > Provided that only the pkgbuild packages depend on the SFW packages > and not the other way around, but we already have that with JDS. To me, it seems incomplete to give up on "SFW make"-built components being potentially dependent on a pkgtool-built one, when it doesn't seem to be directly ruled out. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-discuss mailing list [email protected]
