stuck

[Matt Zimmerman]

On Mon, Sep 18, 2006 at 10:48:09PM +0300, Jani Monoses wrote:
> Hi all,
> 
> We're stuck on the non-technical side of Xubuntu work and would like to 
> find a way to make  progress.

If these are the non-technical problems, I'd hate to see the technical 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.

Splitting out the gconf bindings sounds like a reasonable solution to me.

>      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.

Is this solved now for the general CDBS case, not only for this one package?

> 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'.

Can you point me to the discussion which led to this impasse?

-- 
 - mdz