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

[Loïc Minier]

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

 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.

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

 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.

 For C apps, we have the nice shlibs system, which offers the guarantee
 that your binary will link correctly.  This is a strong system, and we
 lack such a system for Python packages.  Would we have one, I would be
 open to such splits.  I pointed to a draft implementation of such a
 system.  This is what you called "nice but unrelated".

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

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

 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.
   One of the reason I thought the split was proposed was to lower the
 number of pulled dependencies when people wanted to run gnome-ish apps
 on a non-gnome desktop, and I considered that it was not the effort for
 these alien usages.  I've changed my mind on this particular point when
 I understood that Xfce, a major desktop, was relying on Gconf and hence
 on its Python bindings.
   I still consider it would be worthwhile for Xfce to request an
 upstream split of the python-gnome2 bindings as this problem is
 obviously the same for anyone building Xfce (I suppose that you
 currently need all the build-deps of python-gnome2 to build Xfce from
 scratch, hence you need bonobo, gnomevfs, ...).

> There's one advantage of nobody being in favor: you know where you stand 

 Fair enough.

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

 You claimed that Python app writers express deps on python modules,
 they do not.  This was what the example was about.  They express
 dependencies on other upstream sources.  They currently can not express
 deps on python modules.  I wish they would.  Splitting makes it harder
 to get dependencies right because of this generalized upstream issue.

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

 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.

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