Mailinglist Archive: opensuse-buildservice (199 mails)

< Previous Next >
Re: [opensuse-buildservice] Specification for OBS light project concept
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).

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.

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

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 :

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.


"Don't worry, you'll be fine; I saw it work in a cartoon once..."
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups