[indiana-discuss] [Fwd: [desktop-discuss] SFE binary packages for OpenSolaris]

[Bart Smaalders]

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
barts at cyber.eng.sun.com		http://blogs.sun.com/barts