2011/10/21 Eero Tamminen <eero.tammi...@nokia.com>: > Hi, > > On 10/21/2011 04:05 PM, ext Carsten Munk wrote: >> >> That said - if you keep the source packages in sync (as OBS can do) >> and map a x86 version instead of ARM version of each >> interpreted-language-extension through SB2 mapping, it might work. > > ... >> But a definite no to a tools distribution that we map to that's not >> updated so often. It's a maintainability nightmare. Packages that are >> being built should be built using tools that are from the OS they're >> being built for or we're in for a world of hurt. > > IMHO developer tools should be stable, you update them only > at some specific points. Not so that if somebody happens to > upload e.g. a latest GCC or Qemu snapshot to a repository, > that's immediately being used to build everything else. > > Also, everybody should be using the same versions of the tools > (unless they're testing tools upgrade) otherwise debugging their > problems becomes an impossibility. > > > I.e. OS may have several versions of a given tools package, but > which one is actually used for building the software should be > carefully tested/selected[1], otherwise you're in a world of hurt. > > Debugging compiler code generation issues is one of the less > easy things, especially if you've happened to propagate that > mistake also into some other (arm or x86) tools package where > that mis-compile will first appear... > [1] For GCC upgrades I would say that this testing takes months > rather than weeks.
Okay, so that's where OBS's addiction to rebuilds is kind of interesting as it allows fast feedback on these kind of moves. Let me try and explain some things OBS is capable of. As I told in another post, when a package changes in OBS (ie, someone submits a change to the package, or a package it build-depends on changes) and creates a different result compared to the previous build, this triggers the rebuild of any package that depends on the package. If you think in terms of that there's only one OBS project people accept changes into, a misbehaving compiler will of course nuke the entire set of binaries with difficult rollback. So, OBS has a concept called linked projects[1] which is quite useful to reduce risk and improve QA. In the configuration of a new project, let's call it Staging, you go in, say, you want to <link project="some-other-project">. What this does is that it basically makes all source packages in some-other-project appear in your new project and keep it up to date with Staging. If you submit a change to Staging, it does not affect some-other-project. There's a few different modes of this kind of linked build, called linkedbuild, which you can adjust in the repository configuration of a project: all --- all source packages must be recompiled locally in Staging: This will basically recompile every single package in the project and export a full repository with built RPMs. If there's one or more changes to packages different from some-other-project, these changes will be included too in the build. This is useful for let's say, checking if a new compiler breaks something and run full image builds based on "how would some-other-project look like with these changes", but additionally also takes significantly more build power than the next one: localdep -- reuse binaries from the repository you point to (usually some-other-project), but rebuild those packages that has been modified in the project (and hence those) exporting the modified-from-some-other-project to repository. This takes significantly less build strength as it doesn't recompile everything each time, even with simple changes. This is also useful for QA runs. This is useful to check if one or more packages will cause failures in other packages. Developers would typically want to take one of these linked projects to get a set of packages to install into images. There's also other fun things like block - block="never" means that never wait for another package to finish building to start building (ie, 'blocked' state), block="local", only block if it's caused by another package in same project. There is also "use for build" flag, which means "utilize the packages inside this projects for building packages within it". Disable it and it won't wait for other packages within the repo to build - just run every single packages through once (read: use entire build cluster's capacity..) [2] I've used a linked project + no "use for build" to give me a result in 50 minutes on what of the 1400 MeeGo packages would break with Thumb2 enabled - I only cared about the individual packages, so no need to block on each other/depend on each other. Set up a project with new compiler that the project builds against and you have quite fast feedack In sort, OBS offers a lot of facilities that make these kind of toolchain changes/tool changes a lot less risky - you can get very early, accurate feedback and easily make images to be sent for QA. http://xkcd.com/303/ does come to mind with OBS at times. [1] http://en.opensuse.org/openSUSE:Build_Service_Concept_project_linking [2] http://en.opensuse.org/openSUSE:Build_Service_Concept_build_scheduling_strategies BR Carsten Munk _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
