Bugzilla Bug 160991

dev-python/gnome-python-desktop seems to pull in an unnecessary amount of
dependencies. Why does it need to pull in e.g. the totem media player? For many
of us using gnome-light this is causing some headaches when installing
applications that depend on gnome-python-desktop. It seems like many of them
should be moved to the gnome meta ebuild or some other more appropriate ebuild.

Reproducible: Always

Steps to Reproduce:
1. emerge -pvt gnome-python-desktop
2. Watch output
Actual Results:  
Totem, nautilus-cd-burner and gnome-media shows up as dependencies.

Expected Results:  
At least totem and nautilus-cd-burner seems to be totally unnecessary for this
package, shouldn't they be part of the gnome meta-ebuild or some other
appropriate ebuild?

I tried searching to figure out whether gnome-python-desktop acually needs
theese deps and as far as I can see it does not, so they should at the very
least be USE-flag dependent and not unconditional deps.

Makeing them USE-flag based is certainly possible; however, it requires going
through *every* package that can dep on gnome-python-desktop, and seeing what
of it's deps they indirectly use, and adding built_with_use checks in them,
which cause them to fail to build under some circumstances.  This is a lot of
work, for very little gain, which makes me not inclined to do it.  If no one
has gotten to this before use-flag-depends make it into portage, then I'll
revisit; but I personally hate built_with_use checks.

Instead of dealing with Use-Flags, one could use single ebuilds for each module
which gnome-python-desktop contains. So that in the end you have for example:

-pymetacity
-pyrsvg
-pytotem_plparse
-pygtksourceview
etc.pp.

As I already needed pyGtkSourceView as the single widget w/o wanting to have
totem installed, I have written an ebuild for this. Therefore I change the
configure.ac in a way, that only the modules which I needed are built.

Created an attachment (id=109850) [details]
pygtksourceview ebuild

My example ebuild.

to make it clear, you'd like to see a sort of meta ebuild
(dev-python/gnome-python-desktop) which would pull pymetacity, ... the same way
the gstreamer is actually doing ?

(In reply to comment #4)

A meta-ebuild might be a possible solution - but I dont see a reason for it. I
dont think, that there is a project which actually needs all of the modules. So
stating the _real_ needed projects as dependencies makes more sense for me :)

Short: Just split the ebuild - and if someone is really bored he might build a
meta-ebuild ;)

A meta would be necessary, at least until all the deps have been fixed. 
However, I've been involved in maintaining split-up packages before, and it's a
nightmare, so I'm not going to do it.  If one of the other gnomies wants to,
it's fine, just don't look to me to help maintain the monstrosity.  If upstream
splits up, all fine and good, but we have enough work already without making
more.

(In reply to comment #6)
> If upstream
> splits up, all fine and good, but we have enough work already without making
> more.

I dont think they will ever split it up. The configure script looks what is
present and compiles the py-support for theses packages. So basically there is
no problem. - The problem is the ebuild which wants all (possible) modules toe
be compiled and therefor all dependencies to be satisfied...

No, there is a problem.  Programs need to use the code provided by this
package.  These programs need to know that, when the package is installed,
their deps are fullfilled.  This is a problem for all users, not just gentoo. 
Just detecting what's installed is not good engough for any distro; we all need
to have everything installed when it's compiled, or some other program will
fail because the part it uses was not built.  It all has to be there, or we
need to do all the work of maintaining split ebuilds.

Upstream is just as lazy (or busy) as I am, that's all, and is providing python
bindings in two huge packages, rather than splitting them up.  This is changing
slowly; for example, pygtk was split into pygtk and pygobject.

Ah ok ... you are right. I have forgotten, that other distros have
package-managers too ;)

But - just for a guy not having to deal a lot with ebuild-maintaining - why is
it easier to maintain packages split by upstream then maintaining packages
split by Gentoo?

It's because of the nature of ebuilds; A very basic ebuild, with basically
nothing but keywords, deps, and the upstream download location (and for gnome,
that's provided by the eclass, so it's not even necessary) will suffice for the
majority of gnome packages, including this one.  Keeping up with upstream is
easy, because bumps basically involve renaming the ebuild.

If we split it ourselves, then we have to figure out which set of configure
options need to be passed to enable only a specific set of functionality, and
we probably need to patch the makefiles to not install common things, and maybe
change install locations, and a number of other things to get the split
packages to not step on either other toes.  Every bump, we need to work through
this whole set of local changes and make sure they all still work, that
configure options haven't changed, and that any patches still apply.   I
estimate that a typical bump of such a split up package would take me as much
time as bumping 15 - 20 normal packages, compared to just bumping one
(gnome-python-desktop).  That's a big chunk of my time, and doesn't include
handling all the bugs that will show up because I don't know the code well
enough to get it right the first 3 or 4 times...

Generally a lot of work that the upstream maintainers could do much much better
(because they know the code) if that's what they wanted.

To some extent, we (Gentoo) have it harder when it comes to split packages than
binary distros do, because they can do the split after the package is built and
installed on a system that has all the deps, and then package the various libs
into separate (say) rpms with one -base rpm that has the common stuff.  I don't
know of any distros that are splitting up gnome-python-desktop, tho.  Kind of
surprising, it has a *ton* of deps.

You are free, of course, to add an overlay with your own version of
gnome-python-desktop that only has the deps you need.  It should be very easy
to do.

Oh, and one more thing I forgot:  Typcially, other packages have a dep on
gnome-python-desktop, possibly with a minimum version.  If we split, then the
maitainer of every such package needs to dig into the package every  bump to
see which parts of gnome-python-desktop it acually uses, and dep on those split
ebuilds;  Or else they need to dep on the meta, which defeats the whole
purpose.

xeffects overlay has an ebuild with nognome use flag which should suffice to
install less packages and have both python-rsvg and wine doors...

*** Bug 186612 has been marked as a duplicate of this bug. ***

*** Bug 188663 has been marked as a duplicate of this bug. ***

Ok ... the maintainer of pygtksourceview said, that they will have
pygtksourceview-2 as a seperate package :)

"Don't worry I will make sure that the new pygtksourceview will stay in
a separate package, we had a lot of discussions about that and at the
end we decided to keep it as it is now."

Don't know whether this will apply for the other packages too.

Created an attachment (id=136645) [details]
Proposed ebuild not requiring crazy dependencies, based on xeffects ebuild for
2.18.0

This ebuild is modified from the xeffects overlay one to include correct
dependencies for 2.20.0

(In reply to comment #16)
> Created an attachment (id=136645) [edit] [details]
> Proposed ebuild not requiring crazy dependencies, based on xeffects ebuild for
> 2.18.0


This has crazy implicit automagic dependencies and is absolutely wrong for the
official portage tree, as it fails basic dependency QA.
If going this way, then it must be ALWAYS the case that the bindings that are
meant to not be built with nognome are really never built. With this ebuild
that is not true, because they will be built when any of the libraries is
present from the conditional list, which means completely inconsistency in the
known dependencies and real dependencies.

However the proper way for this is to split it up into different packages, each
providing bindings only for one or a smaller set of libraries, with
gnome-python-desktop package being a meta package for all these to retain
backwards compatibility at start.

This bug is related to #108479, which was opened at 2005-10-08. So I'd think
You should either start to fix it or celebrate an anniversary each year ;-)
However, couldn't gnome-python-desktop install and update an eclass? Thus, the
dependencies could just call e.g. "gnome_python_add *me*" or
"gnome_python_remove *me*". The latter could be a problem, because AFAIK
there's no "finalize_ebuild" or sth. similar to give the ebuild a chance to do
cleanup. The "add" could in turn do the necessary testing of python versions
(i.e. the same, as the gnome-python-desktop ebuild does on installation). If
python hasn't been installed earlier, the gnome-python-desktop ebuild should
call "gnome_python_check" to check for packages for which it provides python
bindings. I'd guess this to be simple, at least for the other package
providers.

I'm not sure I understand the proposal.  Are you saying we should have an
eclass that automagically generates ebuilds?

Please explain further, and explain how this solves the problems in comment #1
and comment #10?  If there's a solution that doesn't require us to do tons of
work, I'm certainly open to it.

Created an attachment (id=137155) [details]
A concept (partially)

This is, what I'm thinking about conceptually - nothing working, probably
damaging Your system, if You try to run it - it will not work, because it's not
a real script!

Created an attachment (id=137157) [details]
A concept (partially)

Ooops - accidently uploaded this as text before - may result in unreadable file
:-( so here's the correctly uploaded file (uploaded as application/gzip)

That's not possible in portage, for a whole nubmer of reasons.  It's an
interesting idea, but not really feasible.

Created an attachment (id=146523) [details]
Split gentoo-python-desktop into per-component ebuilds

This splits gnome-python-desktop into several ebuilds. Most of the work was
done by lack in the rox overlay. Noteworthy changes:

1) gnome-python-desktop now *only* provides bindings corresponding to
gnome-desktop

2) gnome-python-desktop-meta provides all bindings (including metacity, and the
new evolution+ecal bindings) (blocker for older gnome-python-desktop to be
added).

3) There's a gnome-python-desktop-base that _only_ installs the pkgconfig file.
This is fugly, but necessary (there's no other way to guarantee that the file
will always be correctly available)

4) gtk-doc support seems broken. Need to investigate.

Please review and let me know.

Created an attachment (id=146525) [details]
Patch to allow individual component selection using autotools

Attaching the patch required to autofoo for those who don't want to download
from my site.

Created an attachment (id=146593) [details]
Split gentoo-python-desktop into per-component ebuilds take 2

New and much-improved patch.

ChangeLog:

0) Don't modify gnome-python-desktop-2.22.0 from the overlay

1) Blocker on <gnome-python-desktop-2.22.0-r1

2) Collision on pkgconfig file fixed

3) gtk-doc stuff works just fine (always did, actually)

I've compared the set of files from the old package with the new meta package,
and things look fine.

This is a really good patch. The eclass looks ok to me and the ebuilds look
good too.

I'm just not 100% convinced we need this, 'tis all :) But I'm still fine with
putting this inside portage if the rest of the Herd thinks it might help us to
do that.

Created an attachment (id=146608) [details]
Split gentoo-python-desktop into per-component ebuilds take 3

Updated again:

1) Renamed all ebuilds to ${name-of-gnome-package-being-wrapped}-python

2) gnome-python-desktop is now the meta package

3) gnome-python-desktop-base blocks older gnome-python-desktop because of the
.pc file collision

4) The meta package doesn't install any documentation (README, INSTALL, etc.)
any more

Created an attachment (id=146651) [details]
List of dependency updates required for split g-p-d

This is a list of dependencies that need to be updated to use the split
gnome-python-desktop. I've generated this by examining all the "import" lines
in the source package.

Remi: Note that only 7 of the 14 modules available are used at all, so I think
this split might be useful.

Also, 3 packages appear to depend on gnome-python-desktop for no reason at all.

(In reply to comment #28)
> Created an attachment (id=146651) [edit] [details]
> List of dependency updates required for split g-p-d

deskbar-applet imports an "_evolution" and "_gnomedesktop". Since I'm not
familiar with python, I wasn't sure if this implies a dependency on these 2
modules. If it does, we need to dep on dev-python/evolution-python and
dev-python/gnome-desktop-python.

duping against 108479 to clean up bugzilla.

Use Arun's git overlay if you want to keep track of this but don't add no need
to comment until the eclass is reviewed on gentoo-dev mailing list since a
review was done last week and Arun is currently away.

Tree: http://www2.cse.iitk.ac.in/~arunsr/git/gnome.git
Branch: g-py-split

*** This bug has been marked as a duplicate of bug 108479 ***