mdz at ubuntu.com
Fri Sep 22 18:49:48 BST 2006
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
> -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?
More information about the ubuntu-devel