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

[Loïc Minier]

On Tue, Sep 19, 2006, Jani Monoses wrote:
> >  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.

 No, I always mentionned the maintenance cost.  I mention various
 maintenance burdens in my original critic on debian-gtk-gnome@, and I
 repeatedly pointed you at the lack of an automatic tool to gather
 Python dependencies during yesterday's discussion.  Yes, I also
 mentionned other counter-arguments, such as Packages.gz bloat -- but I
 also mentionned this is a "minor issue".

 Please do note that I said "we lack *either* manpower *or* appropriate
 technical tools", meaning that would be have the technical tools, it
 would be safer and more acceptable to implement.

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

 The channel is not automatically logged by a bot or something similar,
 I don't log the channel myself, and I'm not aware of public logs of
 this channel being available; hence, I considered it appropriate
 courtesy to clarify whether the attendants would agree in the
 publication of what I found in the buffer of my IRC client.

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

 Would you rather prefer there would be nobody in favor?  I was trying
 to point out that not every Debian GNOME maintainer is against the
 split.

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

 No, they do not.  Take for example's pessulus' ./configure.ac:
    PKG_CHECK_MODULES(PESSULUS,
                      pygtk-2.0 >= 2.6.0            \
                      gnome-python-2.0 >= 2.6.0)
 No "import" is made during configure.

 There's no standard way to declare / express runtime Python
 dependencies in a source today (that I know of).
   The above is already bending the use of ./configure which is supposed
 to check the build-time dependencies.

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

 Yes, it can be done in Debian, or in Ubuntu, or both.  Yes, upstream
 doesn't need/require the split.  But it's still possible to do it
 upstream.

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

 I already responded to your hard critics yesterday.  You're accusing me
 of not answering you, which is unfair given I took the time to try to
 explain why I don't like it and gave precise examples on how things
 could break.  I also replied to your examples, contrarily to what you
 claim.

> >  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 :)

 (And we replied that grep wasn't good enough.)  Here's the start of a
 sample solution to this problem, which I happen to like, and was
 proposed a while ago on debian-python at ldo:
    <http://lists.debian.org/debian-python/2006/01/msg00151.html>
 If you're not fluent in Perl, this open a debian/<package>.pydeps which
 expresses dependencies on Python modules, and resolve this as package
 dependencies via /var/lib/dpkg/info/*.pylibs.  Pylibs and Pydeps are
 written by package managers to declare dependencies between Python
 modules and mapping to packages.
   This still doesn't offer the automatic extraction of the list of
 Python modules that an applications requires, but at least the ground
 is ready.

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

 Well, this has less chances to get you the attention of the people
 which can help the situation.

-- 
Loïc Minier <lool at dooz.org>