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 attachment 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 attachment 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] > 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 attachment 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 attachment 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 attachment 146523 [details, diff] 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 attachment 146525 [details, diff] 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 attachment 146593 [details, diff] 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 attachment 146608 [details, diff] 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 attachment 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] > 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 ***
