[oi-dev] Desktop Illumos Still Matters

Wed Sep 5 17:31:56 UTC 2012

On 5 Sep 2012, at 18:04, Nick Zivkovic <zivkovic.nick at gmail.com> wrote:

> 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?

Userland already has a perfectly good build system.  I don't understand what you're trying to accomplish here.

Andrew S.

> 
> 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
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev