On 5 Sep 2012, at 18:04, Nick Zivkovic <[email protected]> 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 > <[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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
