[oi-dev] Desktop Illumos Still Matters
Alasdair Lumsden
alasdairrr at gmail.com
Tue Sep 4 22:39:58 UTC 2012
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.
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
More information about the oi-dev
mailing list