Alvaro Lopez Ortega wrote: > Darren Kenny wrote, On 12/12/2007 12:34: > > > Personally, I would have liked the IPS system to have also included a new > > OpenSolaris build system too, like Debian packages do, which would be used > for > > *all* packages, > > Let me clarity this. The Debian packaging system (dpkg) does not have > a special build system because it is not needed. > > Dpkg can use whatever building mechanism the source package is based > on, and therefore there is no need to reinvent a new one for it. It > can build autotools based programs, plain make, cmake or anything else > that can be invoked from a script - a Makefile target, actually. > > Personally, that is the main reason why I cannot still understand by > the IPS packages doesn't support binary to source packages references > and rebuilding. > > There would not be any need to impose a new building system. We could > have implemented the binary to source link and keep using the original > compiling mechanisms without any kind of problem (as Debian does). > > Having the links and order (one to one, one to many, etc) between > source and binary packages, the compiling support should be a > different layer of abstraction and would be up to each one which > compiling mechanism they base their applications on. > > > but that's not how it's done right now, and I don't know if there is > > any intention on going that way unless the community really push for > > it... > > I do hope so.. I have used that a million time on Debian. It is a > really handy way of taking advantage of having the source code > available. >
IPS doesn't include a build system for the same reason it doesn't specify an IDE to be used for editing source files - it's not the problem we're trying to solve. The prime requirement for a build system is reproducible builds; given the proper tool chain, and build machine OS release, anyone can produce the same set of bits anywhere from the source code. Today, Sun's build environments are broken into "consolidations"; these are sets of software built at once, with internal dependencies resolved from the just developed bits. This allows us to consider interfaces purely internal to the consolidation as private, and since all components of the consolidation are always built and delivered as a set, we can avoid having to carefully version and control those private interfaces. In other words, if I can update all the producers and consumers of an interface w/ a single putback or push or commit, I avoid significant disruption and flag days, etc. Dividing most current Solaris consolidations into source packages that could be build separately would require a very substantial amount of effort to careful version and control all private interfaces. This effort would not enhance the software at all; at best, we'd end up w/ the same bits we're producing today after very substantial amounts of work. Given the resource constraints we're working under, breaking up the existing consolidations (esp. ON) into various source packages just isn't in the cards. As a result, we're focusing on producing IPS packages from a variety of different inputs - first, svr4 packages, since that allows us to boot strap the existing consolidation builds. Next, we'll probably build directly from a proto area; adding tar ball support, rpms. etc is also quite possible. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
