On Fri, 23 Feb 2007, Stephen Hahn wrote:
* 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.
Help, I must be missing something: SFW make-built components can't
currently be dependent on components outside the SFW make system? I guess I
thought they could...
Eric
_______________________________________________
opensolaris-discuss mailing list
[email protected]
