* Laszlo (Laca) Peter <[EMAIL PROTECTED]> [2007-02-23 12:22]: > On Fri, 2007-02-23 at 11:51 -0800, Stephen Hahn wrote: > > > 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, > > In fact we use chroot jails for running the JDS nightly builds, although > for a different reason -- it allows us to use the same build machine > for building different things. It also gives us confidence that we > know our dependencies. Build machines are not always, but often, shared. As I understand it, this has been a constraint on use of pkgbuild outside JDS.
> > > 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. > > Okay. So what's wrong with starting to build a spec file base > separately and when SFW is ready to use them, we merge the 2 > together? > If changes need to be made to pkgbuild for this to happen, I'm > happy do so. It depends on your objectives--if you're just hoping to offer packages as an OpenSolaris effort, then a merge can be delayed indefinitely (as it seems to have been in the past); if your aim is to offer a set of binaries that get picked up by the distributions, as those of ON are, I would suggest pursuing a merge as a primary objective. Which would mean engaging with /os/projects/sfwnv/ and extending that effort's output... - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-discuss mailing list [email protected]
