[oi-dev] Desktop Illumos Still Matters

[Nick Zivkovic]

On Tue, Sep 4, 2012 at 5:39 PM, Alasdair Lumsden <alasdairrr at gmail.com> wrote:
> Hi All,
>
>
> 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.

Well, incorporations sound like a great feature, imho. I guess the
only problem is when two packages have mutually exclusive dependencies
(foo depends on libbar.so.1, and baz depends on libbar.so.2). But even
then, one can probably avoid this by using NGZ's, if the foo package
isn't updated to use libbar.so.2, or if that software is no longer
maintained by the original author.

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