>>>> 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. > > So as I've thought about it, I propose we adapt this a little and aim > at providing a nice development environment that provides a good > integration experience for embedded-style developers (or middleware - > typified by being command-line oriented, non-gui types who'd prefer a > chroot/vim/emacs solution to a pointy-clicky gui). This must be > attractive to the early assesment teams and yet should support scaling > up to a productionised integration process (since as an 'initial > investigator' I certainly don't want to evaluate something, find I > like it and then find that scaling up loses me the things I like). > > Dominig, does that sound reasonable? Yes, the UI is primary there to help to do the first step without having too much hassle while all commonly use feature must be available as well in command mode. This is why the UI focus on simple thing which are not repeated several time and the key features which will be used all day long (rpm patch creation, image creation) must work from command line to enable shall script automation. This is why we plan to expand osc and mic2 not replace them. > > I'd like to identify the main pain points and address them in benefit > order. Can we do this via a wiki page based on some of the points in > the pdf. > >>> 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. > > Completely agree for verified builds, and of course a normal 'osc > build' will continue to do exactly this - but you're talking about a > developer environment. Do you really want 10-20 active development > chroots if you dabble in 10-20 packages? What if you do arm and x86 too? Our plan as you have seen in the Spec is to let the user indicate the packages that he wants to work on and to create 1 chroot (big) which includes all of them. Then we want to automate patch creation and allow to push them back in OBS. From there the build normal script can be used again. > > This would be a special 'fat' build environment made up of the sum of > all specified build dependencies. I need to re-verify this > 'requirement' - it kinda makes sense, after all that's what scratchbox > is. I'll probably run these ideas past the people who originally > suggested them to see what priority I personally have for this > capability (currently it is just a "nice to have" idea). > > Don't forget that any package developed here would still run the > integration gauntlet which would involve a server-side minimal build > as usual. > >>> * updating chroot efficiently? >> >> cowbuilder FTW! Copy on write. > > I'm not familiar with cowbuilder. What I meant was that as rpms become > available (eg a package is integrated into the build-target I'm using) > how is my chroot updated without cleaning it and rebuilding it? > Simply doing : rpm -i <new_dev.rpm> sounds sane .... but how to check > what rpms need updating? I need to get look at Cowbuilder. Where do I find documentation ?
_______________________________________________ MeeGo-distribution-tools mailing list [email protected] http://lists.meego.com/listinfo/meego-distribution-tools
