[oi-dev] Desktop Illumos Still Matters

Wed Sep 5 17:04:35 UTC 2012

I think that Andrew want to use a unified build system, instead of the
loose confederation of radically different systems that's currently in
use.

I agree. A unified build system is necessary. The only question is:
what should it be?

Makefile-based, like ports/pkgsrc/oi-build?
specfile-based?
tcl-base like macports?
shell-based like Gentoo's and Exherbo's?
python-based like conary?

I'm fine with any of the above (as well as any that I've not mentioned).

As long as we end up with a standardized build system so that
contributors can cross-fertilize consolidations instead of confining
themselves to just one.

What do existing OI-contributors think?

Anyone know what the most technically-superior or technically-advanced
build system is?

On Wed, Sep 5, 2012 at 11:05 AM, Andrew M. Hettinger
<AHettinger at prominic.net> wrote:
>
> Andrew Hettinger
> http://Prominic.NET || AHettinger at Prominic.NET
> Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
> Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l)
>
>
> Alasdair Lumsden <alasdairrr at gmail.com> wrote on 09/04/2012 05:39:58 PM:
>
>> On 04/09/2012 22:42, magnus at yonderway.com wrote:
>> > On Tue, 4 Sep 2012 13:25:39 -0500, "Andrew M. Hettinger"
>> > <AHettinger at Prominic.NET> wrote:
>> >
>> >> One of the biggest issues here isn't that packages are particularly
>> >> HARD
>> >> to
>> >> make with IPS (they aren't). It's that there are about three different
>> >> approaches to it, and we need to get that standardized. Many of the
>> >> packages are tied up in the consolidations, which DO seem to have a
>> >> high
>> >> barrier to entry.
>> >
>> > So what are the cliff's notes to the three different approaches, and is
>> > one
>> > of those approaches going to have a lower barrier to entry with still
>> > high-quality results? I'm thinking along the lines of a third party
>> > repo.
>>
>> I think there's a bit of confusion surrounding the terms involved.
>>
>> A consolidation is just a logical grouping of packages, such as "JDS"
>> (Java Desktop System, renamed to just "desktop" on Solaris 11), "SFW"
>> (Sun Freeware, replaced with "userland" in Solaris 11), etc.
>>
>> The big issue is that all the consolidations use different build
>> systems. JDS uses RPM style spec-files similar to SFE (Spec files extra,
>> a collection of 3rd party package recipes). SFW used a horrible Makefile
>> based system. Userland is an excellent replacement for SFW, and uses
>> Makefiles but in a way very similar to the FreeBSD ports tree or pkgsrc.
>>
>> I was attempting (with some others) to get OI updated in a "giant leap
>> forward" replacing SFW with userland-gate (renamed to oi-build, and
>> later illumos-userland after Nexenta started meddling). The idea was
>> that we would try to focus on one single build system, the userland-gate
>> style, which is the best of the lot. New software would go in there, and
>> if we needed to update something in another consolidation, we would
>> instead re-implement the recipe for it in userland-gate format.
>>
>> Unfortunately my approach with /experimental was quite ambitious and
>> didn't quite work how we wanted.
>>
>> Jon Tibble is continuing to release new OpenIndiana builds (such as
>> prestable 6, released *today* -
>> http://wiki.openindiana.org/oi/oi_151a_prestable6+Release+Notes) and is
>> advocating we do move to a single build system based on userland-gate,
>> but more slowly and in a more controlled fashion.
>>
>> oi_151a actually already has a mini userland-gate/oi-build, which you
>> can see here:
>>
>> https://hg.openindiana.org/sustaining/oi_151a/oi-build/
>>
>> It's used to deliver some additional software and some bits from other
>> consolidations have been moved there.
>>
>> It is probably where people should focus their efforts moving forward.
>>
>> Incorporations are probably what people are bitching about, which are
>> there to provide "lockstep" upgrades between known working version sets
>> of software. "entire" is the best known incorporation, which with each
>> release locks all system software at a particular version.
>>
>> Incorporations are needed to prevent your system getting shafted. Lets
>> say you are on oi_148, and in oi_151a we introduced some new software
>> called "foo". Foo depends on version 2.0 of "bar". oi_148 delivers "bar"
>> version 1.0. Without incorporations, if you "pkg install foo" it will
>> upgrade "bar" no questions asked. Any software linked against bar
>> probably just stopped working with libbar.so.1 changed to libbar.so.2.
>>
>> Incorporations present a challenge when you're developing software,
>> because they stop you installing new versions of things. The way to get
>> around this is to have "empty" incorporations on your development
>> system, that way you are free to shaft your own install if you want to.
>> It's like taking your seatbelt off.
>>
>> Incorporations map to consolidations, so SFW, JDS, etc each have their
>> own incorporation. This means the incorporations have to be updated when
>> you move software from one consolidation to another, eg from JDS to
>> oi-build.
>>
>> Hope this makes sense.
>>
>> Alasdair
>>
>
> I used terminology sloppily, thank you for clarifying for everyone.
>
> Source Juicer used the same RPM style spec file that SFE uses, with a web
> frontend to automatically handle submitting and building packages. What it
> lacked as a simple way to promote a package once it had been testing for a
> while. And the process for getting that done that was always a thorn in all
> of our sides. As I recall, for someone on the outside, it was "badger the
> right people in sun until you where annoying enough that they'll do
> promotions just to get you out of their hair". Even for all it's problems,
> it was a really good system, which (atleast for those of us who knew about
> it) strongly encouraged contribution.
>
> I feel that as long as there are so many differing build systems, people
> will tend to confine themselves to one of them, and not be as productive as
> they can be.
>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev