stuck

[Jani Monoses]

Hi all,

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 
deps.
   -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 
2.16 prepared.

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
https://launchpad.net/distros/ubuntu/+source/gnome-python/+bug/60615

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)

thanks
Jani