GNOME Bugzilla – Bug 419879
[RFC] consider having -HEAD modulesets
Last modified: 2009-05-11 18:36:33 UTC
Now that we have 2.16, ..., 2.20 and everyone is happy with that, we are changing the way jhbuild used to be working. In the past, each module was named differently when a release version was stick to it. I can imagine the pain it caused then, because each module that depends on it needed to be updated. Anyway, it is not easy to checkout dbus, cairo, hal... from HEAD/trunk versions nowadays. I would suggest that we add -HEAD.modules, that includes the latest current version (2.20) and overrides the modules definition if necessary. (btw, that's how I workaround this problem)
Furthermore, this modules do not follow strictly the GNOME release dependency. We could include more modules for testing. Each release would be a copy/update from the previous release (2.18->2.20), not HEAD-2.22 for instance. I have already some -HEAD.modules.
*** Bug 365747 has been marked as a duplicate of this bug. ***
This was partially the reason for the split of freedesktop.modules and freedesktop-2.18.modules; the former being for those wanting to build from TRUNK/HEAD/whatever while the latter being for the official release cycle uses (users could then just make gnome-2.18.modules point to freedesktop.modules instead of freedesktop-2.18.modules). I'm not sure we kept that up with 2.20 (since we now have gnome-external-deps-2.20 or something similarly named), but it makes sense to me. However, I don't think -HEAD sounds like a good name; fewer and fewer modules are using cvs these days. Just my $0.02.
(In reply to comment #3) > However, I don't think -HEAD sounds like a good name; > fewer and fewer modules are using cvs these days. > > Just my $0.02. > Yeah, I know, HEAD is ugly (CAPITAL and so on... ;). But trunk is svn specific... and HEAD is more familiar and nearly everyone understand it. -vcs, -scm.., -snapshot?, -edge.. Ok then, one can keep up to date freedesktop.modules, gnome.modules... instead. I did not want to touch those files, because they are used by gnome-2.12/14/16. If we start changing things here, then we should remove the old modulesets that have a dependency.
(In reply to comment #4) > Ok then, one can keep up to date freedesktop.modules, gnome.modules... instead. > I did not want to touch those files, because they are used by gnome-2.12/14/16. > If we start changing things here, then we should remove the old modulesets that > have a dependency. gnome-2.12/14/16 are utterly broken anyway; they depended on freedesktop.modules, which has always been the latest cvs/svn/whatever. GNOME modules at the time may have built against e.g. the latest dbus, but will they anymore? There's been multiple API/ABI changes. I'm almost certain that those ancient GNOME versions wouldn't build against the latest development version of all freedesktop modules. I'm betting the only way to get them to compile is manual intervention anyway. *shrug*
I am never crystal clear with my comments ;) - Should we remove old/deprecated 2.x modulesets? - Can we start submitting patches to have gnome.modules, freedesktop.modules up to date all the time using (as much as possible) repo & growing list of modules (PK, CK, various dbus bindings, goo/cairo/Xext.., more gnome svn modules - nemiver...) ?
Howdy, I fully support the idea that we should have both nice stable modulesets and a bleeding edge/wild-west moduleset. The way that I have been doing it is by adding a "custom.modules" and making that my default in .jhbuildrc. It looks something like this: <include href="gnome-2.18.modules"/> <include href="freedesktop.modules"/> That way I override the freedesktop-2.18 modules set in the gnome-2.18 set. Even better would be to make a link called "gnome-devel.modules" to the most recent "gnome-X.XX.modules" file. I'll attach a proposal.
Created attachment 84889 [details] wild-west.modules And we should add a gnome-latest.modules that never uses a stable branch.
I was quite sure the wild-west.modules had been commited; looks like I was wrong; could you commit it, and gnome-latest.modules ?
It's quite long task to come up with new -latest modules that are complete and working. here is what I propose: We currently have modules such as name-version.modules. Those perfectly fit the job for branching. Instead of choosing WWW/latest/HEAD/trunk/whatever, I would simply use the same named module (ie name.modules) to describe how to build the latest vcs version. Most of the packages in name-2.22.modules are still using vcs version. We don't need to copy them now in name.modules. However, some of them are already branched. Then we can just define them in the corresponding latest moduleset (name-version -> name): Ex: gnome-external-deps-2.22 has HAL version 0.5.9. gnome-external-deps could then have HAL head, with different depepdencies. That way, we can do a case by case. (I am not sure about this approach, but it's the best solution I have so far:)
Of course, to use them, one would have to define correctly the "moduleset" order in .jhbuildrc: moduleset = [ 'gnome-2.22', 'gnome', 'gnome-external-deps', 'gnome-suites', 'freedesktop' ] That way, the vcs moduleset can keep in sync with the branched moduleset (they share the same moduleset name)
Coming a bit late to the party, but I'd suggest having -stable, -unstable and -trunk. The first two help people always have the latest stable/unstable version of GNOME, even when we start a new cycle. -trunk would help for people wanting the bleeding-edge.
Created attachment 109557 [details] override some branched/tarball modules This is the modulesets I use to build wild wide west. It works like that. moduleset = [ 'gnome-2.24', 'gnome-suites-2.24', 'gnome', 'gnome-suites', 'gnome-external-deps', 'freedesktop', 'pulseaudio' ] I check with jhbuild info when modules are branched, and add a new entry in the overriding modules when necessary. I did not find a better easy way so far.
So, apparently, the freedesktop.modules has been removed from svn. That seems to be contrary to what we want to do here.
freedesktop.modules has been renamed to freedesktop-2.14.modules, as that was what it was. Creating wild west modulesets is the second step. In its latest attachment Marc-Andre created modules that selectively override modules that are not using trunk in our otherwise latest module sets (2.24). His idea is to keep adding overrides, so building with both 2.24 modules and "wild west" modules gets you all trunk modules. The alternative would be to create freedesktop-latest, gnome-latest, gnome-suites-latest, etc. module sets listing all modules; bigger job now, but tracking changes later would not be necessary. I don't have an opinion on this as Marc-Andre is doing all the job :) However I think those modulesets should have -latest (or -trunk or -head or whatever) in their names.
Created attachment 118626 [details] latest version
Eh Marc-Andre, going back at this, wouldn't it be enough to have a flag to ignore all revision and tag attributes, so new modulesets wouldn't have to be maintained at all.
Frederic, to be frank, it has been quite some time I didn't build full gnome set using this www approach. I don't know if jhbuild evolved and can let you decide to checkout alternative branches. I guess having overriding modulesets is still easier. Also, how do you solve dependency changes? (like with gnome-2.99?)
(In reply to comment #17) > Eh Marc-Andre, going back at this, wouldn't it be enough to have a flag to > ignore all revision and tag attributes, so new modulesets wouldn't have to be > maintained at all. That wouldn't work for turning tarball modules to svn/git/etc modules (e.g. for the external dependencies).
Created attachment 134301 [details] latest version
Would you commit and maintain them?
But you should first add a -devel to the filenames (-devel being neutral, as -trunk or -master or -head are no longer appropriate)
OK! this in work in progress. I managed to compile more than 120 modules from the meta-gnome-desktop this week-end. I just had to fix all the davidz autogen.sh ;) commit cb290aea0434a4d726a858c5648478f1ed193195 Author: Marc-André Lureau <marcandre.lureau@gmail.com> Date: Mon May 11 21:24:10 2009 +0300 [*-devel] add new modulesets to override branched modules