On 2013-05-09 13:06, Andrzej Szeszo wrote:
The process you have described sounds a lot like OI's original plan. It didn't work out. There was too much baggage. No one was willing to spend time learning it. It was just too ... ugly.
It's possible to try it differently this time :) One way or another, in these consolidations we have tons of source code, which, one way or another, need a process to build them. Even if the system of build scripts, spec recipes, makefiles and so on would be changed to something else, just to develop this new build logic and to check validity and comparability of the resulting packages we (individual developers) need to be able to build it "the old way" and "the new way" (whatever that would be). AFAIK, very few people know what to do to create the binaries and packages in the old techniques, which makes it problematic for others (not "in the know") to start improvements or from-scratch rewrites. Of course, some architectural overview or general framework for all consolidations of what we want to achieve as the new build system (i.e. "conforms to this list of technical requirements: A, B, C... Z") would be needed. I may be wrong to think that ability to build the whole beast in the old ways is useful to make the new building technology, but lack of it also hinders an ability to make new spins of the whole OI distro or just updated package repos, as one other commonly-requested useful result of the overall OI project. So far most users can rebuild the "kernel" part (illumos-gate) of their installations and third-party code like updated sendmail, apache or whatever they need to update, rebuilt and installed in traditional unpackaged ways into alternate paths or even overriding the system binaries, but that's about it. And this is wrong, especially for SOHO farms of several OI machines or zones which could otherwise reuse the in-house updated packages automatically and properly :)
Individual gates provide some semi-automated ways of building things. I don't know anyone who managed to automate them all though. No one was able to provide equivalent of "make world" to build complete OI to date.
There are occasional requests on the list from people who are willing to give it a try, and look at the same bits of knowledge from their perspective. If those are shared, including the info on what works and what doesn't and hypotheses on why it doesn't, it is possible that just by sheer increase of the number of eyes, hands and brains aimed at parts of the problem, it would budge and give in :) After all, most "manual" administrative tasks can be scripted with mega-scripts of logic based on practical observations (do this, check that, don't do this if...). If someone formulates the problems in English, others can translate them to bash or perl or make scripts...
There is no doubt Martin Bochnig has a lot of expertise in putting operating systems together. I got impression that he was heavily invested in SVR4 based systems though. OI may not be an interesting project for him as it will probably remain IPS based for the time being.
I did lose track of what he implemented in the end, but I think his builds did rely on existing IPS manifests, and he had fixed quite a few, and the SVR4 packages were built using automated backports of the IPS metadata. IF this assessment is correct, then it is more a matter of taste - which packaging system the resulting OI distro would use, either format would come from same sources. //Jim Klimov _______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev