Splitting the GNOME Python bindings for Xfce (Was: stuck)
jani.monoses at gmail.com
Tue Sep 19 12:14:25 BST 2006
> 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.
> (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 :)
> 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.
More information about the ubuntu-devel