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

[Jani Monoses]

>  No, I always mentionned the maintenance cost.  I mention various
>  maintenance burdens in my original critic on debian-gtk-gnome@, and I

There are no maintenance costs at all, that's why I found that argument
unsubstantiated.

so quoting your 5 critics here,

  1) these transitions are a lot of work

There is no transition to make except an optional per package change of dep.

  2) not a gain until the next stable release because of the partial
     upgrade guarantee which forces us to have compatibility deps which
     pull everything

It is a gain for the specific apps and situations I mentioned in the OP.
The fact that those apps are not installed by default in debian indeed 
make this a less urgent issue there but it is still a gain, however small.

  3) python-gnomish build-deps and deps are hard to get right already
     (just found a new missing dep today on a package which I had
     carefully reviewed for sponsoring multiple times already)

This is a separate issue independent of how the bindings are split. If a
python app uses gnomevfs (as the gedit bug you mentioned) the packager 
should find out which package provides it and add it to the dep. Which 
incidentally would be easier if that package was called python-gnomevfs 
instead of python-gnome2.

  4) because there's no clean mechanism for upstream to express runtime
     deps, some upstreams use build time checks for runtime dependencies,
     these might break too because of the split; the one to one mapping
     between binary packages and upstream modules is a good thing until
     this problem is addressed

The split itself cannot break anything. Only a careless update of a 
package to make use of the new split ones. So it is opt-in as I 
repeatedly said, and if something breaks it means someone consciously 
tried to switch to the new split scheme and forgot some deps. This 
happens often with both C and python apps and a new upload ususaly fixes 
the problem. But this is in no way an argument against the split.

And in the cases where upstream does this and is confusing you can just 
leave everything as is now and nothing is lost.

  5) these packages are aimed at machines where GNOME and Python are
     installed, do these need the space saving?

They are not aimed at anything in particular. They are written using 
python gtk and a few other libs and usable in any environment; that does 
not imply that the GNOME desktop is necessarily installed even if it is 
in the majority of the cases. The same thing as with Gtk apps written in 
C, there should be no assumption of GNOME or else Gtk would not be a 
separate library.

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

The automatic dep gathering is a separate issue. It may be the largest 
current problem of the python bindings and a good one to have solved but
it should not block solving other unrelated ones as this.

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

There's one advantage of nobody being in favor: you know where you stand 
and can decide whether you fix the problem or drop it, it's entirely up 
to you, in either case you can plan accordingly.  When there are 
uncertainties and arguments and promises the whole thing can linger on 
and get nowhere because noone was firm enough to say 'No'. This happened 
to me quite a few times already with various upstreams, so I prefer a 
straight answer. In this case, people being in favor and people against 
it only means progress if they keep debating the pros and cons not just
reassuring outsiders that both sides are defended and there is hope.

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

I don't know what that module check is trying to achieve and whether 
there are better ways to do it in python apps. The .pc file is provided 
by the python-gnome2-dev which depends on python-gnome2 so this again is 
in no way affected by the split.

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

No, you both kept avoiding to explain why the simple split and update of 
one gconf using app would be wrong. Look at the log a few lines before I 
logged out.

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

This is nice, but unrelated to the issues I originally contacted you about.

Jani