GNOME Bugzilla – Bug 635594
Module selection/injection in jhbuild config
Last modified: 2010-11-27 16:54:49 UTC
I want to make module selection/overriding possible and would like to ask if this has the chance of getting upstream. Let's say someone has a glib repository with the module-id 'mrx/glib' and wants that to be used in place of 'glib'. The configuration would look like: modsel = { 'glib' : 'mrx/glib' } When assembling the moduleset, the module 'mrx/glib' would be inserted as 'glib'. This way you would not have to modify other modules that depend on glib. So far so good, but there are two more things I would like to support: First, optionally taking the dependencies from the main module (glib in this case), unless there are explicit dependencies in the selected module (mrx/glib in this case). This would facilitate writing modulesets and would keep sync unless explicitly disabled. Second, I would like to support making small mods to the dependency list. This would be helpful in case there are branch specific dependencies, and you don't want to write a new moduleset just for this branch. The configuration could look something like the following, but I'm totally open to other ways of arranging it: modsel = { 'glib' : 'mrx/glib' } adddeps = { 'glib' : 'gtk-doc-plus' } removedeps = { 'glib' : 'gtk-doc' }
What I want to do is basically imitate what would happen if there are these module definitions (the second overriding the first). <autotools id="glib"> <branch/> <dependencies> <dep package="gtk-doc"/> </dependencies> <after> <dep package="shared-mime-info"/> </after> </autotools> <autotools id="glib"> <branch module="~mrx/glib" checkoutdir="people/mrx/glib"/> <dependencies> <dep package="gtk-doc-plus"/> </dependencies> <after> <dep package="shared-mime-info"/> </after> </autotools> There would be an optional argument to moduleset.load() to get the raw module list, which could be used to act on all modules.
Created attachment 175360 [details] [review] Add the concept of selectable forks It is now possible to define a fork of a module in a moduleset and select it instead of the main module with the fork_select configuration variable. A fork can comprise a whole new module or just a branch. The forks will be injected into the list of modules under the name of the module they fork. Add attributes to the ModuleSet class that, represent available forks and replaced modules in form of the new class ForkedModule. Add a fork_name attribute and a real_name property to the class Package. The latter will generate the fork_name if it is set and fall back to the normal name. This can be used to inform about forks in a purely informational display. To define forks, there are the two new XML elements <fork-module> and <fork-branch>, which are described in a new documentation section.
Created attachment 175361 [details] [review] Modify dependencies through the configuration Depending on which branch is selected or which build-configuration is active, there might be small adjustments to the dependencies of a module necessary. Allow to make such modifications with the new configuration variables module_deps_absolute, module_deps_add, and module_deps_remove.
Created attachment 175362 [details] [review] Add tag_revs configuration variable Similar to the configuration variable 'branches', allow to override Git tags in a moduleset with this new configuration variable.
The three patches rely on each other somewhat. So, I post them all here, but the first one is the important one. This is how the fork/clone select solution looks like: It is possible to define a fork of a module and select it instead of the main module with the fork_select configuration variable. A fork can comprise a whole new module definition when wrapped into the fork-module element. <fork-module name="forkname"> <autotools id="modulename" ... > ... </autotools> </fork-module> To only replace the branch of the main module, it is possible to wrap a branch definition into the fork-branch element. <fork-branch name="forkname" id="modulename"> <branch ... /> </fork-module> In both cases the id attribute specifies the main module for which this is a fork. --- I don't know DTD, so this is just a guess: <!ELEMENT fork-branch (branch)> <!ATTLIST fork-branch name CDATA #REQUIRED> id CDATA #REQUIRED> <!ELEMENT fork-module (autotools|tarball|distutils|perl|linux|testmodule|cvsroot|cvsmodule|waf)+> <!ATTLIST fork-module name CDATA #REQUIRED>
It is already possible to alter the definition of some modules, you just have to load an additional moduleset (eg moduleset = ['gnome-suites-3.0', 'my-overrides']); I don't see any benefit in a new way to achieve this.
The current method relies on overriding. To arbitrarily mix there would have to be a moduleset for every single repository. The benefit of this patch is that there are all repositories for one module available (no overriding), and can just be selected through the configuration. Let's say there are these repositories, and there are modulesets for both airlied and anholt: ~airlied/xf86-video-intel ~airlied/xserver ~anholt/xf86-video-intel ~anholt/xserver How to test the anholt driver on the airlied server? With this patch it would be possible to just configure: fork_select = { 'xserver' : 'airlied/xserver', 'xf86-video-intel' : 'anholt/xf86-video-intel', } There could be one moduleset for all of Xorg and developers could specify a test case just in form of a small configuration file. The burden to manage a modulesets for every developer would disappear.