jani.monoses at gmail.com
Mon Sep 18 20:48:09 BST 2006
We're stuck on the non-technical side of Xubuntu work and would like to
find a way to make progress.
* Some context:
Besides the xfce desktop Xubuntu also ships some (and plans to ship
more) gnome/gtk apps which are already part of the Ubuntu desktop
install. To keep the resource usage lower we try picking only the apps
which have no gnome dependencies. That means we avoid most of the gnome
libs except gconf2, gnomecanvas, gnomeprint, gnome-keyring and gksu.
This selection reflects somewhat the gnome/gtk separation that is being
done upstream as project ridley and related efforts, mostly because
these are libs useful outside of the gnome desktop itself where there's
no emphasis on tight integration.
* The problems:
There are two separate issues which prevent further addition of such
apps while also keeping the resources low as planned. One affects python
apps the other C ones.
* Python apps which use some leaf gnome libs
The python-gnome2 bindings are one monolithic debian package. If
an app has an import gconf for example it needs to depend on
python-gnome2 which in turn depends on most of the gnome libs. Same for
gnomecanvas. Similarly gtkhtml2 which depends on pythom-gnome2-extras.
For these the resource I am concerned about is space taken up on the CD
and dist-upgrade bandwidth once they're installed.
On a system where gconf is already installed, instead of getting a 200K
installed size package which contains the python binding ( 2.4 and 2.5
builds of a single .so) we get 4.2 Mb download which uses 29Mb when
installed. For python gnome extras this is an additional 4M of download
and 30Mb of installed size. So in addition to the gconf or gtkhtml2
bindings, bonobo, vfs, esound, avahi, totem and libnautilus-burn related
libs and utilities are installed
The python apps that would benfit from such a split are:
-update-manager - currently detects gconf at runtime and falls back
to a simple text config to avoid a hard dep on python-gnome2. It only
needs the gconf binding.
- gnome-app-install - needs gconf and gtkhtml2. Since none are split
out it depends on the 60M installed size of gnome-python-extras and its
-onboard - uses gconf
-hwdb-client - uses gnomecanvas
Only update-manager is in xubuntu now. It would be easier if it did not
have to deal with gconf detection and only depend on python-gconf. The
others are not part of xubuntu as of now, but would be good to have.
* C apps which have a --disable-gnome build-time option.
In this case besides the install size and bandwidth, the resources
we're concerned about are memory usage (even if those libs are shared)
which can lead to earlier swapping and startup time.
There is an advantage in having ubuntu and xubuntu app selection
overlap so we fix the same bugs and have less packages to maintain. So
instead of havig galculator in xubuntu we should have gcalctool
(upstream has a disable gnome option). Instead of xscreensaver have g-s-s.
For this it was agreed that having separate source packages for
the two types of build is not optimal. The only current cases are
evince-gtk and xubuntu-system-tools. They are equivalent to evince and
the gnome-system-tools packages with the addition of patches to make
them build without gnome libs.
A better way that was suggested is to build the two binaries from
the same source so updates, especially urgent ones are done in only one
place. While no urgent updates were needed for these two packages it is
a good general principle anyway to avoid duplication.
The problem with this approach was that in CDBS, the packaging
system most of these packages use it is not straightforward to run two
builds with different options one after another. Gauvain Pocentek has
worked on this recently, getting gcalctool to build with both gnome and
gtk only variants.
So from a strictly technical pov these two issues are solved. The
problem is that since they are packages maintained by the gnome team we
cannot modify them which is ok, but we cannot convince them to apply our
patches either which is not :) The reason is according to Seb that we
should not diverge from debian. I agree we should not gratuitously
diverge from debian. So I talked for over an hour today to two of the
debian-gnome packagers about the python bindings split which led to no
outcome as they are not interested in splitting the package and instead
of a good argument against it they gave several not so good ones IMHO.
And just like Seb sent me to them, they sent me to upstream python-gnome
:) So that looks like a dead and especially since they are still getting
How can this particular issue be solved? Ubuntu has diverged from debian
or pioneered stuff when it made sense before. It is just that since
gnome maintainers care primarily about gnome it is hard to convince them
that this is a case that 'makes sense'.
The changes that need to be don from our pov to the current packages
mainatained by gnome are:
- split python-gnome2 and python-gnome2-extras so we can use gconf,
canvas and gtkhtml2 individually. There's no transition to worry about
for apps that don't care. Those that do can change their deps to the new
split-out package, the others can keep depending on the full one and
nothing will change for them.
bug in LP and patch
The app maintainers (g-a-i, onboard) are willing to change the deps if
such a split happens.
- modify the cdbs scripts of a few packages to run two build passes.
Some may need an extra debian/patch but I am working on getting those
upstream so that is optional (i.e. gnome-system-tools)
More information about the ubuntu-devel