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

Alvaro Lopez Ortega alvaro at sun.com
Wed Dec 12 23:20:10 PST 2007


Bart Smaalders wrote, On 12/12/2007 19:33:
 > Alvaro Lopez Ortega wrote:
 >> Darren Kenny wrote, On 12/12/2007 12:34:
 >>
 >>> 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.

There is not need for that, actually. There could be source packages
that would produce many binary packages; that is why I said it would
need both the source to binary relations and order of those relations.

Let's imagine the worst possible case: you need to build the complete
ON consolidation in order to get a little binary package built. It
would not be perfect, but it would be much better than having nothing.

In fact, I suppose that we will eventually start dividing big
consolidations into packages -think of JDS, it is big set of
independent source packages.

So, my points were:

  - Having source packages and binary packages relations is really
    useful. In fact, it is something that has proved to be helpful in
    other OSes and that many users miss.

  - There wouldn't be any *real* need to change the consolidation
    system. It wouldn't be very efficient because of the large builds,
    but again, that would be much better than missing the feature. And,
    in fact, we are using LOT of F/OSS software that is not based on
    that sort of consolidations.

  - I would have said that the state of the art kind of forced us to
    implement it. Even if you wanted to think of it like a
    "nice-to-have", it is a very important one if you think that we're
    targeting developers.

-- 
Greetings, alo.


More information about the indiana-discuss mailing list