GNOME Bugzilla – Bug 675873
Separate modulesets
Last modified: 2021-05-17 15:53:27 UTC
As jhbuild grows into a standalone tool with tarball releases that is perhaps even shipped by distributions, it becomes more pressing to separate the data from tool, so we don't end up in murky situations where we co-develop the data format and the tool thats reading it. At the same time, we can move from the somewhat odd -version suffixes to using proper branches and tags for modulesets. We have a working module with the 3.4 and 3.6 modulesets here: http://git.gnome.org/browse/gnome-modulesets The other pieces that are needed are 1. publish the modulesets from that module on api.gnome.org 2. change jhbuild to default to that location 3. update documentation to point to the new, final location (hard to say where, but at least going over the jhbuild docs and live.gnome.org would be advisable) 4. drop the modulesets/ directory from jhbuild
Makes sense to me. I in fact just did the same thing with ostree: http://git.gnome.org/browse/gnome-ostree/tree/
I filed bug 675934 for the sysadmin side of this bug.
For jhbuild, what must be done: - change defaults.jhbuildrc moduleset variable to be http://api.gnome.org/modulesets/$version/gnome.modules (or whatever location ends up decided in bug 675934) - change jhbuild documentation to mention the moduleset variable should be a URI (or a list of URI) - add fallback (or error message?) when that variable is just the moduleset name (important as jhbuildrc all over the place will have things like "moduleset = 'gnome-world-3.6'") - remove the then obsolete use_local_modulesets config variable As a transition measure we could keep the modulesets/ directory in jbhuild, with only 3.6 files changed to be a serie of <include ...> to the new location. This would avoid people commiting changes to those while giving some time to people upgrading their jhbuild copy.
It would be also convenient for me if jhbuild was distributed without gnome modules. Any chances this will happen?
Created attachment 300097 [details] [review] Change fallback URI
Created attachment 300098 [details] [review] defaults.jhbuildrc: change 'moduleset' variable to new location
Created attachment 300099 [details] [review] docs: moduleset varialbe should be a URI
Created attachment 300100 [details] [review] moduleset.py: raise an error if moduleset varialbe is not an URI
Created attachment 300101 [details] [review] Remove the new obsolete use_local_moduleset config variable
Created attachment 300102 [details] [review] moduleset.py: raise an error if moduleset varialbe is not an URI.v2
Branch available here: https://git.gnome.org/browse/jhbuild/log/?h=jjardon/gnome-modulesets
I wouldn't want to break compatibility with existing jhbuildrc files, modulesets should continue to allow strings. Also they should allow file:/// URIs and that should be documented.
As long as we're pushing URIs it would be nice to be able to set a base uri (file or https) and have string moduleset values appended to it.
(In reply to Frederic Peters from comment #12) > I wouldn't want to break compatibility with existing jhbuildrc files, > modulesets should continue to allow strings. Also they should allow > file:/// URIs and that should be documented. But we are changing the name of the moduleset from gnome-apps-3.16 to gnome-apps (or in a different branch, if you want to build a older version) Are we sure we want to keep compatibility with this big change? If yes, any idea about the best approach in python (sorry, not a pythonic person here)
I have now pushed support for a <redirect/> tag: commit eea3ce6be0fbe8b6b9f0ca3ea9bb11c5d2835a9e Author: Frédéric Péters <fpeters@0d.be> Date: Thu Apr 9 18:26:06 2015 +0200 add support for a <redirect/> tag, to be used when modulesets are moved It will be used to keep existing instructions and configuration files working after modulesets are moved in their own repository. <redirect href="https://git.gnome.org/browse/gnome-modulesets/plain/gnome-core.modules?h=gnome-3-16"/>
Writing down that URL as an example reminded me we need a stable location, we do not want to depend on cgit being installed on git.gnome.org and serving the files using those paths and query strings. Bug 675934 was marked as obsolete when the sysadmin moved to RT, I'll reopen it now that they're back on bugzilla.
(In reply to Frederic Peters from comment #15) > I have now pushed support for a <redirect/> tag: > > commit eea3ce6be0fbe8b6b9f0ca3ea9bb11c5d2835a9e > Author: Frédéric Péters <fpeters@0d.be> > Date: Thu Apr 9 18:26:06 2015 +0200 > > add support for a <redirect/> tag, to be used when modulesets are moved > > It will be used to keep existing instructions and configuration files > working > after modulesets are moved in their own repository. > > <redirect > href="https://git.gnome.org/browse/gnome-modulesets/plain/gnome-core. > modules?h=gnome-3-16"/> Great! I reworked the https://git.gnome.org/browse/jhbuild/log/?h=jjardon/gnome-modulesets branch to use the <redirect/> tag I only left the gnome-apps-3.[18|16|14] and gnome-world modulesets files for compatibility. Is that enough or should we leave more files in the jhbuild repo?
We should leave the moduleset.dtd/rnc/xsl and schemas.xml for validation purpose. We also have to keep th bootstrap.modules as it's used internally, at least for now. As far as the branch is concerned, I would also go with John Ralls' comment #13 to have a base uri setting; this would be set by default to https://api.gnome.org/jhbuild/modulesets/3.16/. Talking about that URI, I thus reopened bug 675934 but this probably needs to be more actively pushed.
*** Bug 742041 has been marked as a duplicate of this bug. ***
Is there any plans to finish this?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/132.