[oi-dev] Desktop Illumos Still Matters

Wed Sep 5 17:49:26 UTC 2012

Someone thought it would be a good idea to have a unified build system
across consolidations.

I think it's a pretty good idea to standardize on one build system.

I'm merely asking which one would be preferred by the community
(assuming the community would be willing to standardize).

On Wed, Sep 5, 2012 at 12:31 PM, Andrew Stormont
<andyjstormont at gmail.com> wrote:
>
> 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
>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev