[Meego-distribution-tools] Specification for OBS light project concept
jeremiah.foster at pelagicore.com
Sun Jun 19 13:48:44 PDT 2011
> 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.
> 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?
I don't think so. I think we have a minimal chroot - in fact the
smallest possible. Then when you build your package you'll see that
you're missing dependencies that you didn't notice you needed. This is
how pbuilder and cowbuilder do it and it helps illustrate some of the
assumptions developers makes about what users have on their systems.
> * updating chroot efficiently?
cowbuilder FTW! Copy on write.
> * 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)
Sounds tricky to keep up to date.
> 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/
I've used this, it can be adapted to rpm and to the upcoming SPDX,
hopefully. We ought to keep an eye out for future compatibility with
SPDX and being able to use bits of alien to go arbitrarily from RPM
<--> DEB and back again.
> 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.
Good idea. How about fakeroot when root is needed?
More information about the MeeGo-distribution-tools