> > I'll have to take a more serious look at how you guys are presently > creating the SI and what the exact requirements are. From what little I > have seen however, some of the recent additions in CVS, the way we now > build, may be quite helpfull. > > Anyways.. I have some ideas, however I think I should get myself a > little more imformed first :) >
I especially like the way we multi stage build. This really helps cut down the edit,compile,debug cycle. Something we are discussing currently is how to deal with conditions. There is a desire for one set of xml to work on all of the architectures. This means optional packages, architecture names being used as variables (entities), etc. We are currently using nalfs because we had the most success with it. There has been some discussion on hardening it against a build failing so we can restart builds. Gerard mentioned to me that the LFS group was redesigning their automated tools. Another issue with the XML is the use of <exec> in the code. I have found this to hide problems and also to break restarting of busted builds. This has lead us to talk about adding some new tags and reserving exec for only a few items and future use. To futher delineate LSB SI from the LFS xml files I am in the process of renaming the entities and cleaning up comments. Just wanted to say this in public so no one misconstrued this as hiding the origins. It would be in cvs already but I took a trip last week. Please, comment on changes we have made or improvements you have made in your own branch. I have thick skin (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
