Just a quick blog to point you at the external dependencies branch of JHBuild i’ve been working on.
The external deps branch aims to do 2 things:
- Don’t jhbuild any modules that are already system installed
- Add a new command to jhbuild to install system packages so they don’t need to be jhbuilded
It pretty much works, it needs massaging into shape to merge into master. Then we need to collect some meta-data:
- Minimum versions. How do we know if the system installed glib is new enough? I added a minimum=”" annotation to the dependency information we already have.
- Package names. Right now it’s a bit difficult to map jhbuild module names to package names. I’ve added aliases files for now, and some crude python to try and infer the aliases for Debian. Better ideas welcome.
I also need to get round to a PackageKit backend so it supports more than Debian/Ubuntu :]
If you want a jhbuild where ‘jhbuild build gedit’ only builds the least amount of stuff, help me :]
Tags: JHBuild
Chocolate train!
You sir, rock!
We’ve had big problems with jhbuild-built python modules when not building python in jhbuild. Is there any plan to deal with them?
Yay !
This is the only thing preventing me from using JHbuild (I don’t have enough bandwith and patience to download all gnome libraries from git). I wanted to do this but couldn’t find the time. I’ll be happy to help. (btw, the link has an extra http://)
For package names, I think the best idea is to try to do a contents search (searching for the pkg-config file for a library). this has been discussed on Anjuta mailing list (there is also bug #558856 on gnome bugzilla)
Nice work, thanks. I cannot help you for now, still need to learn a lot about this.
I think this is a great idea!
Concerning mapping of versions, you should pay attention to “epochs” in Debian/Ubuntu packages.
To map GNOME packages to Debian/Ubuntu packages or vice-versa, I think we could add meta-information to the packages themselves, in the source package which would be copied in the binary packages (e.g. you would have the GNOME module information just next to the package name and version). This does call for clearly defining what we put in there: mixed case upstream name? Do we limit to modules which have a repo at svn.gnome.org or git.gnome.org? Or those that install tarballs on the GNOME FTP? etc. We do such mappings in the source packages already to allow retrieval of the .tar.gz from upstream when calling get-orig-source.
There’s also the problem of splitting: gnome-python might be split into python-gconf and python-gnomecanvas, evolution-data-server libs are split in a gazillion of lib-dev packages etc. I think this is a harder problem which calls to express finer grained dependencies in jhbuild modulesets (e.g. I need this .pc or this .so to build), perhaps making the current names aliases to standard definitions (if you say you dep on gnome-python that expands to a dependency on all python modules shipped in this module).
I’m happy to help you on the Debian/Ubuntu packages front.