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? 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 <[email protected]> wrote: > > Andrew Hettinger > http://Prominic.NET || [email protected] > 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 <[email protected]> wrote on 09/04/2012 05:39:58 PM: > >> On 04/09/2012 22:42, [email protected] wrote: >> > On Tue, 4 Sep 2012 13:25:39 -0500, "Andrew M. Hettinger" >> > <[email protected]> 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 > [email protected] > http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
