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

[Jani Monoses]

>  You seem to consider here the case of a new package or an existing
>  package being reviewed after a split.  I mostly mentionned new upstream
>  releases of current software, but my arguments also apply to the
>  packaging of new packages: with split python packages, you can not rely
>  on the upstream documentation or the upstream dependencies checks in
>  configure to get the Debian deps right.  It is your proposal which
>  introduces the need for "grep"; we could live without until now.

When in doubt python-gnome2 can be used as it will cover what it does 
now by depending on the split packages. This is what I mean by no risk 
at all for packagers who don't care about the split.

So we can have the gains I was originally after (g-a-i, update-mgr, 
onboard) and just rediscovered today that ldm (the LTSP display manager)
is also relying on gnomecanvas. Because of the python-gnome2 dep there 
are ~4M unused debs on the xubuntu alternate install CD (which is 
oversized now unrelated to this, but not having those debs would help)
> 
>  Indeed, we can make it so that the split does not break the other
>  packages.  But once you start converting packages, or when you prepare
>  a new source package from scratch, or when you prepare new upstream
>  releases, the burden is here, and you have to check all imports instead
>  of just the NEWS/README/INSTALL or configure.
> 

I agree. As I said above, for packages with complicated ot hard to 
discover deps we can do as today. The gain is still present for the 
cleaner packages.

>> And in the cases where upstream does this and is confusing you can just 
>> leave everything as is now and nothing is lost.
> 
>  (I don't understand this paragraph.)

Again, as above ;) . When the package is confusing nothing needs to be 
changed so nothing can break. That there are apps which do not correctly
specify their deps should not mean that all apps should depend on the 
whole gnome python for fear of breakage. The apps I picked were all 
clean enough that I could see they only need specific library bindings.

>  Let me reword that argument: it seemed to me -- but this was only my
>  feeling -- that machines where python-gnome2 is installed are desktop
>  machines, with plenty of disk space.
>    However, in the light of this discussion, I consider that there are
>  some particular parts of these packages which might be useful for Xfce
>  (say, the Gconf Python bindings), and for which a split would be nice.
>  Please note that this argument appeared in the (general) discussion on
>  debian-gtk-gnome at ldo which was not focused on Xfce in particular.  I
>  have changed my mind on this particular argument in the light of Xfce
>  using Gconf.

Only one Xfce app (xfce-session) uses gconf and it is optional. But 
since Xfce is not much more than a core desktop without as many 'native' 
apps as GNOME or KDE, to have a working desktop you'll have to pick from 
a variety of sources. And these are the ones that are likely to use 
gconf or other libs. For example the xubuntu desktop is xfce core + many 
gtk apps which where originallyu developed for/around the GNOME desktop.

So Xfce upstream is unlikely to care much about python-gnome, but it's 
different with a distro if you want as much as possible out of the box.

> 
>  At this point, I really can't bear being told I avoided answering you.
>  If you don't want to listen to the answers, you should not be asking
>  questions in the first place.  Certainly, in the kilobytes of emails
>  and IRC text that I typed, there was only avoidance of discussion,
>  denial, and not answering of your questions.  So much for openness to
>  discussion.
> 

I perceived openness to discussion only after writing here, in the 
kilobytes of mail, but not on IRC. Sorry if my tone two days ago
was unfriendly. It was the result of frustration of not getting any 
progress done after other attempts during all of which I tried to start 
the dialogue friendly and proposing to do the work myself, and being 
ignored or driven away by unconvincing technical arguments.

Jani