Splitting the GNOME Python bindings for Xfce (Was: stuck)

[Jani Monoses]

>  This is a bit one-sided.  You should at least mention that we suggested
>  that we lack either manpower or appropriate technical tools to handle

Before getting to manpower which can be a wildcard argument against any 
change whatsoever, you also said it is useful only for very few users, 
that is has transition and testing costs and that is causes bloat in 
Packages.gz. None of which are convincing IMO.

>  Python dependencies in a split scenario.  (For my part, I'm fine to
>  publish the unstripped IRC log as documentation of the discussion; if
>  you agree and sjoerd does, I suppose it would be nice.)  This was also

I don't see why agreement is needed to publish the logs of an already 
public channel. I asked twice yesterday whether the channel is logged 
during our discussion because I wanted to point others who did not 
participate to it. I got no answer.

>  brought up in a thread on debian-gtk-gnome at ldo, which is less complete
>  than the discussion we had yesterday.
>   <http://lists.debian.org/debian-gtk-gnome/2006/08/threads.html#00040>
>  (Please note that in this thread, Josselin was originally in favor of
>  such a split, so hope isn't lost. :-)
> 

One dev in favor does not mean anything. You can argue endlessly unless 
all of you agree until the issue is dropped because all parties get on 
to other things.

>> 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.
> 
>  Again, this is slightly inaccurate.  I suggested that half-seriously,
>  as one of the possible options to solve your proble: if there's some
>  real need for having a split python-gconf, isn't that need existing
>  upstream as well?

It may exist, but one advantage of packaging vs upstream tarballs is 
that it can take advantage of the package system and additional metadata
to provide a nicer (in this case more finegrained) installation 
experience. The ruby gnome2 bindings are such an example: coming from a 
single upstream tarball, mapping to a single debian src package but 
providing many binary packages.

$apt-cache showsrc ruby-gnome2


>    Since currently Python application maintainers express dependencies
>  on other *sources*, this would help them express dependencies of their

Python app writers express deps on python modules. So it would be better 
if a python module translated directly to a debian package so the 
packager does not need to figure our where to get that module from.
gconf and canvas are such python modules.

>  applications on "python-gconf and only python-gconf", instead of having
>  to depend on python-gnome as they currently do.
>    Hence, I really think there is some ground to convince upstream to
>  split the package exactly like libglade-java is not in libgnome-java.
>  I doubt they would like the additional maintenance cost though.

They do not need to split it can be done in debian/ubuntu.
> 
>  We certainly did not suggest that bringing it upstream was the *only*
>  solution, or to stop the discussion.

You did not have to suggest it. Talking over an hour with you two and 
getting nowhere was enough. Your not answering to questions raised on 
_specific_ examples, instead of talking generalities in a somewhat 
patronizing tone and finally saying 'it's better to end the discussion 
now' were good reasons enough for me to start spending my effort 
elsewhere. I am also pretty convinced that had I not written this mail 
yesterday the issue would have been dropped. Just like the ML thread you 
  pointed out as evidence that work is being done.

> 
>> 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'.
> 
>  It certainly makes sense.  Nobody ever claimed that such a split would
>  be useless or wouldn't help or wouldn't make sense.  Most claims were
>  on the maintenance burden, lack of tools, etc.
> 

Lack of tools for what? You said yesterday that it is to much work for a 
packager to find out what modules a python app uses and this can lead to
problems with missing deps. I suggested grep :)


>    Bye,
> 
> PS: Would be nice if you could put more keywords in the Subject of your
>     messages; I skipped the message thinking it was spam or some random
>     user complaining he was "stuck".

Honestly could not think of a better one. I tried to avoid a subject 
which could be perceived as too political so I did not put (x)ubuntu, 
gnome or debian in it.