I apologize for top- and in-between posting, and perhaps somewhat naive thinking, but I just couldn't stop for my brains for making stupid question(s): Since most developer hardware are capable of running virtual appliances (using Vmware's player, KVM, or other such software) would it be out-of-reach of obs/osc developers to implement osc as VM client node, which would register itself to OBS service as a build node. If a local OBS would be used, then the full build environment could be part of the VM appliance and the build process would be executed in local workstation. All required configurations, repository settings and such would be included to the project by local system admin. Perhaps all developer tools [editors etc], which are required in that project, should be included in appliance which would allow really "standard desktop implmentation"; if such is needed. After development cycle, the cleanup of development desktop would require just the deletion of local VM appliance. All other VM benefits would also be included, such as distributed build process, platform independent development, load balancing etc. 06/19/2011 09:07 PM, David Greaves kirjoitti:
On 14/06/11 13:44, Dominig ar Foll (Intel OTC) wrote:
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.
I'm also looking at making OBS fit more easily with the developer workflow in a sizeable MeeGo/OBS project in Teleca/LGE. (And by developer I don't mean just the elite code hackers who inhabit lkml etc; I need to cover junior devs too).
Could the developers in this project use "standard" environment, which would actually exist as a virtual desktop, or virtual appliance? Would it be plausible in resource wise?
My initial thoughts had been to prepare something like: * osc chroot : to prepare a clean build area, probably with gdb etc too * mount -bind /path/to/vcs-managed-src /path/inside/chroot/src * developer hacks and saves in their 'desktop' environment * osc 'rebuild' : runs rpmbuild with hacks but without cleaning chroot. (since I did something like this a couple of years ago)
Issues include: * support multiple packages in one mega-chroot? * updating chroot efficiently? * not rm -rf'ing a build chroot with a mount -bind .git tree (!) * create a project or team specific meta-package which depends on various useful rpms to allow osc build -x my_dev_env to be easy.
How much of this could be achieved with implementing more modular installation setup of the packages or just in coding process of developers? [this was not a real question, just thinkin aloud :]
I really haven't had time to properly analyse my requirements or the possible solutions so this is very much a hand-waving and a "me too" email.
I will say that I'm in favour of a solution using a real OBS - an appliance VM would be fine.
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.
This seems too hard to support in any meaningful general case. How do I know if the Makefile that just appeared is because I made it or because I ran autoconf? OK, you could just support modifications but then you risk losing real work in new files.
I was going to allow access to git inside the chroot and probably looking at some git/quilt workflow for those who like the patch approach. There is a very nice policy in a supporting tool in debian's git-buildpackage which I'm in the process of 'porting' to rpm over the next week (I hope). see : https://honk.sigxcpu.org/piki/development/debian_packages_in_git/
Some plugin like "osc trialbuild" would use that policy to extract patches from the git tree and update the spec; send them to the OBS and build there.
In embedded we are targeting a developer population which works in the chroot directly.
Agreed. One of my first patches to OBS was to make the UID of the chroot user match the real user so you could use the 'desktop' editor against the chroot path.
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.
Whilst this isn't precisely my goal, I know that a reasonably large subset of devs (especially in the hardware adaptation layers) will have come from that area so I'm also interested in making their environment seamless as they move into a production use of the OBS in their integration workflow.
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.
I wonder if we can start by providing some useful wrappers, workflows and the like around osc and the current system?
NB. If there's not much interest on the obs list then I'm happy to continue discussions on the meego-distribution-tools list.
David
If this sounds even slightly interesting, I can explain more deeper. If this has been said earlier allready, I apoplogize, but I haven't noticed that. yours, Tommi -- WasaLab Oy, P.O.Box 365, FIN-65101 Vaasa t2r@wasalab.com, tel +358-44-767 7770 helpdesk@wasalab.com, tel +358-45-130 4000 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org