This response was sent to the [email protected] mailing list
too and includes comments from Adrian and Dominic
On 14/06/11 09:49, Dominig ar Foll wrote:
The goal of the project is to ease the access to OBS for embedded
developers and initial investigation team which have to select an
embedded OS, by creating a tool which follows their traditional
development process (working locally in chroot) but keeps the
compatibility with the OBS.
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).
Some of the module that we are planning could potentially be of interest
for the real OBS (called Full OBS in my spec). In particular the the
automatic creation of patch files from a modified chroot and the UI for
MIC2 could become generic features. All created new code will be GPL2.
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. It may be possible to create a standalone dependency calculator
but surely anyone seriously evaluating MeeGo is also interested in integration
and team development too? As such I'd favour:
a) improving the docs on installing a MeeGo OBS appliance
b) providing 'offline' support for osc build (ie cache the dependency calc)
>> 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 (or a
proper local rpmbuild - the dev can run 'make' at any time.)
> 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?
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-distribution-tools mailing list
[email protected]
http://lists.meego.com/listinfo/meego-distribution-tools
