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