I had a brief look and I did not understand if you plan to use just the "build" script directly or if you are about to invent something else. For the build part we plan to reuse the build script. No need to reinvent the wheel. The build script can be used complete standalone at least or embeeded in osc local builds or obs service side builds. Yes osc can do that. What osc does not do easily is to re-extract the change done in the chroot to create a patch to apply to the original
package. In embedded we are targeting a developer population which works in the chroot directly. One of their first need to is to run makeconfig to change the kernel configuration and create a config patch. What is not that simple with the existing tool set.
So is it a problem that an OBS server exists at all for these developers ? Yes. The selection of an OS is generally done by a team of a few guys generally under the CTO office. These guy are normally given a few weeks to check a few alternative OS and as new projects are often "top secret" using an OBS requires to install a private instance.
Once you add the complexity of the task (intermediate I would say) to the embedded culture of these teams, you really sees that OBS can be a major obstacle to MeeGo selection while it is a fantastic tool that would be very useful for the future of any embedded project. OBS Light target to feel that gap.
Or would it be find to do a local build via "osc build" in chroot using the resources from a remote OBS server ? If you look at the UI in the Spec you will notice that we are planing to allow the dual mode (local or remote OBS repo as reference). Our goal is to help embedded project to move to OBS.
Some part OBS light will be created as plug-ins to osc (e.g. the patch creation tool) and that could be of a general value for all OBS users. -- Dominig -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org