| Summary: | [Tracker] Split gnome-python bindings | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | WerK <werkon> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexandre.marcelo, awickedshimmy, bassul, fauli, generalpenguin89, jorge.vargas, kevinlyles, magnus.ahlberg, nbenitezl, peach, peter.nabbefeld, pva, rb6, riklaunim, rockoo, ulm |
| Priority: | Lowest | Keywords: | PMASKED, Tracker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | Pending Removal: 2011-12-21 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 268485, 270944, 352910, 352911, 352912, 352914, 352916, 352917, 352920, 352922, 352924, 352926, 352927, 352928, 352929, 352932, 352934, 352935, 352937, 352938, 352939, 370961, 372161, 372165, 372167, 372169, 372171, 372173, 372175 | ||
| Bug Blocks: | |||
| Attachments: | use flags for gda and spell | ||
|
Description
WerK
2005-10-08 05:45:36 UTC
Its not just easy enough to modify and put in the xxx?(). The configure.in does not have real switches, thats why all those things are not useflagged. I have a patch locally that enables the switches that I will submit upstream shortly. Created attachment 82598 [details, diff]
use flags for gda and spell
It really is that simple as adding the use flags and optional deps. The configure script is written in such a way that it just doesn't install these components if they are not found. I don't need a spell checker nor gda, so I used this and it worked fine.
(In reply to comment #2) > Created an attachment (id=82598) [edit] > use flags for gda and spell > Does this really works? > It really is that simple as adding the use flags and optional deps. The > configure script is written in such a way that it just doesn't install these > components if they are not found. I don't need a spell checker nor gda, so I > used this and it worked fine. > I'm having exactly the same issue with mozembeded, it's trying to pull all kinds of stuff. any thoughs on this being implemented? *** Bug 128911 has been marked as a duplicate of this bug. *** *** Bug 140312 has been marked as a duplicate of this bug. *** *** Bug 141732 has been marked as a duplicate of this bug. *** Well I think it's the better place for my problem. It is : When firefox USEflag is enabled, gnome-python-extras require mozilla-firefox while mozilla-firefox-bin is installed. Is this a correct behaviour ?? In any case, I thought it just needs to replace firefox? ( >=www-client/mozilla-firefox-1.0 ) by firefox? ( >=www-client/mozilla-firefox-1.0 || >=www-client/mozilla-firefox-bin-1.0 ) or equivalent in the ebuild file but it didn't work. Could you help ? It is a correct behavior since firefox-bin doesn't provide Gecko libs for other applications to use. It's basically stand-alone. You need either firefox or some other package that provides a gtkmozembed library. Mozilla (and then Seamonkey) used to provide it, Firefox does, XulRunner will in the future, but right now Gnome (and the Gnome herd) only supports Firefox and XulRunner. Since XulRunner is not an official part of Gentoo yet, you'll need to build mozilla-firefox. This is a completely different bug altogether. (In reply to comment #8) Ok, thanks a lot for all these precisions R (In reply to comment #8) Ok, thanks a lot for all these precisions Rémy. I'll wait for the XulRunner to be included in the tree. But for now, I emerge mozilla-firefox to satisfy this regular depence. *** Bug 150780 has been marked as a duplicate of this bug. *** *** Bug 158795 has been marked as a duplicate of this bug. *** I'm against adding USE flags for components until we have use-based deps. The current built_with_use system is horrible, and results in tons of failures to emerge. Once we have use-based deps, I'm willing to revisit this. Marking LATER wrt Comment #13 Jakub, please don't touch like that bugs that are not assigned to bugwranglers, thank you. Retitling for the real solution (which we have an example of how to do now for gnome-python-desktop) and reopening... The real workable solution involves splitting the actual bindings into multiple packages and making gnome-python-desktop a meta package that pulls them all in (and results in all the same things getting installed as far as files go). Major build system massaging and a "would be nice but very low priority" kind of thing, and I don't believe any of the gnome team searches for RESOLVED LATER to ever find these bugs again, so keeping it open... waiting on updates of Ford_Prefect which should happen really soon (tm). I'll be duping bugs concerning this topic to clean up bugzilla. *** Bug 160991 has been marked as a duplicate of this bug. *** *** Bug 192351 has been marked as a duplicate of this bug. *** (In reply to comment #16) > waiting on updates of Ford_Prefect which should happen really soon (tm). > I'll be duping bugs concerning this topic to clean up bugzilla. Time-frame for update is about one week. Sorry for the delay. Real-life stuff. :| (In reply to comment #19) > (In reply to comment #16) > > waiting on updates of Ford_Prefect which should happen really soon (tm). > > I'll be duping bugs concerning this topic to clean up bugzilla. > > Time-frame for update is about one week. Sorry for the delay. Real-life stuff. > :| Latest tree can be got from http://gitorious.org/projects/g-py-split/repos/mainline (it's a page with links to the git:// and http:// repository). Branch is still g-py-split. Major changes since the last time -- feedback and (dare I ask?) testing welcome. :) I'm not quite sure how this is supposed to work. I cloned the git overlay, unmasked everything necessary and emerged gnome-python-desktop. It just wants to install everything that the old version wanted (incl totem, etc). There don't seem to be use flags to set options. I'd love to test this, but can't for the life of me figure out what I'm supposed to do.... (In reply to comment #21) [...] > I'm not quite sure how this is supposed to work. I cloned the git overlay, > unmasked everything necessary and emerged gnome-python-desktop. It just wants Well, it's still work in progress. Currently, gnome-python-desktop is just a meta-ebuild which is supposed to be functionally equivalent to the old gnome-python-desktop ebuild. The idea is that once this is in-tree, packages can start depending on only those modules (e.g. dev-python/gtkmozembed-python which they require. Only people who explicitly want all packages need to install gnome-python-desktop itself. In the mean time, it'd be great if as a first step you could use the meta ebuilds as replacements for the monolithic ebuilds and verify that nothing breaks. Thanks! sorry there is no relation whatsoever between these bugs. yes, I'm having the same issue. I emerged screenlets from the desktop-effects overlay and now my beautifully lightweight gnome-light installation is crammed with totem and nautilus cd burner and the likes :( it would be really helpful to have some use flags for all the additional stuff gnome-python-desktop pulls in. I really see no need for it to come with totem or volume control or what not... (In reply to comment #24) [...] > it would be really helpful to have some use flags for all the additional stuff > gnome-python-desktop pulls in. I really see no need for it to come with totem > or volume control or what not... As mentioned in comment 20 and 22, this is being worked on. We hope to have this in-tree soon, after which individual packages will be able to depend o the modules they need. sry, I missed that... so how much till it gets into portage? how can I help test it? (In reply to comment #26) > sry, I missed that... so how much till it gets into portage? how can I help > test it? This still has to be tested and then committed, after which each package that uses any of these packages needs to have its deps updated. So the only real answer is "when it's ready". In the mean time, it'd be great if you could get try the ebuilds in the overlay mentioned above and report any issues here. Thanks! FYI, split gnome-python is now in tree. Will update when gnome-python-desktop and gnome-python-extras are done. I know bugzie isn't the place for it, but I applaud your work on this. (In reply to comment #29) > I know bugzie isn't the place for it, but I applaud your work on this. Thank you! gnome-python-desktop bindings are in. gnome-python-extras, and dependencies of all three are pending. *** Bug 242640 has been marked as a duplicate of this bug. *** FYI, gnome-python-extras is now in, I'll keep working on fixing deps around the tree as Arun will be mostly away until december. *** Bug 249206 has been marked as a duplicate of this bug. *** converting to a tracker bug so we can open bugs and get rid of monolithic deps. See: http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python-desktop http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python-extras Currently, excluding blockers dep: * gnome-python: 61 revisions using it * gnome-python-desktop: 30 revisions using it * gnome-python-extras: 34 revisions using it (In reply to comment #34) > converting to a tracker bug so we can open bugs and get rid of monolithic deps. > > See: > http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python > http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python-desktop > http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/gnome-python-extras > > Currently, excluding blockers dep: > * gnome-python: 61 revisions using it > * gnome-python-desktop: 30 revisions using it > * gnome-python-extras: 34 revisions using it > Is this still in-progress, or even desirable given the proper USE dependencies now in EAPI-2? how does this related to default IUSE at all ??? (In reply to comment #36) > how does this related to default IUSE at all ??? > It doesn't, but it relates to the split packages...I was under the impression that there was a move away from splitting upstream sources in Gentoo now that the USE dependencies are sanely handled. Hm. But what provides gnome-python-2.0.pc now? (In reply to comment #38) > Hm. But what provides gnome-python-2.0.pc now? # qlist dev-python/gnome-python-desktop-base /usr/lib/pkgconfig/gnome-python-desktop-2.0.pc This is depended on by all split python bindings ebuilds so you don't have to worry about that. (In reply to comment #39) > (In reply to comment #38) > > Hm. But what provides gnome-python-2.0.pc now? > > # qlist dev-python/gnome-python-desktop-base > /usr/lib/pkgconfig/gnome-python-desktop-2.0.pc This has a different name and pkgconfig search for gnome-python-2.0 fails... Actually absence of gnome-python-2.0.pc file kept dev-python/nautilus-python from being ported to split gnome-python bindings and although now I've modified configure script to avoid this check I'm still interested in more clean fix to submit upstream. Sorry I meant: $ qlist dev-python/gnome-python-base /usr/lib64/pkgconfig/gnome-python-2.0.pc It's the same logic for all three original bindings providers. All deps should be fixed, should I hardmask metas for removal or we want to keep them for any other usage? (In reply to comment #42) > All deps should be fixed, should I hardmask metas for removal or we want to > keep them for any other usage? Let's get rid of them. None of these packages will ever get updates again anyway. Done |
