Emerge of KDE 3.3.1 causes dependency issues because kdebingings 3.3.1 is not present. Reproducible: Always Steps to Reproduce: 1. Emerge KDE 3.3.1 2. --sync 3. emerge -up world Actual Results: [ebuild UD] kde-base/arts-1.3.0 [1.3.1] [ebuild UD] kde-base/kdelibs-3.3.0 [3.3.1] [ebuild UD] kde-base/kdebase-3.3.0 [3.3.1] [ebuild UD] kde-base/kdenetwork-3.3.0 [3.3.1] Expected Results: No dependancy bakclevels I copied kdebindings-3.3.0.ebuild with some minor updates (SLOT, DEPENDS, remove patch) and that seemed to work - but I leave that to the experts.
Would you mind attaching your working ebuild? I'd like to give it a try.
Same problem for me...
Just committed 'split' kdebindings (3.3.1) ebuilds into the main portage tree. Testing is solicited - I intend to unmask them soon. Split ebuilds for all the other kde-base packages are available at kde-metaebuilds.berlios.de. What this means: you can now emerge just the bindings you want (or all of them, of course) as separate packages with interdependencies and so forth. The new packages are all in the kde-base category (and the kdebindings-meta package depends on all of them).
Closing, kdebindings are being distributed as splitted ebuilds currently.
kde: we have a little problem here: currently the most recent stable kdebindings ebuild on x86 is 3.2.0 (3.2.0!), and even that is broken now, since I cleaned up old kde ebuilds (leaving only 3.2.3 in the 3.2.x series) (Sorry for that, I should have really thought more about it before doing it, I just forgot about kdebindings, sorry again...) However, the fact that nobody complained about kdebindings-3.2.0 being the only stable on x86 makes me think that nobody actually uses it... Should we just remove the monolithic kdebindings from portage and only rely on the split ebuilds and on kdebindings-meta?
Even so, we should fix it quickly. AFAICS we only have these two choices: 1. Add kde 3.3.0 back. 2. Remove kdebindings 3.3.0, add a move instruction for kdebindings 3.3.x -> kdebindings-meta. Normally I'd vote for (2). kdebindings-3.3.0 is a _lot_ buggier, ebuild-wise, than kdebindings-meta-3.3.2. And we don't want to tell users to stick with kde 3.3.0 just for the bindings. The problem is keywords. kdebindings-3.3.0 has KEYWORDS="~x86 sparc ppc". kdebindings-meta-3.3.{1,2} only have ~x86. BTW, the 3.2.x kdebindings series had ~hppa and amd64 keywords too. The ~hppa one, though, doesn't appear in 3.2.3, only in <=3.2.2. We can promote kdebindings-meta-3.3.2 from ~x86 to x86, but the other archs apparently really don't care about the bindings... Is it OK not to leave any usable/modern 3.3.x bindings around with non-x86 keywords? Do any other ebuilds have deps on kdebindings with ppc/sparc keywords?
I'm ok for 2. Can't we request to the other archs to test them?
ok for 2, too, and to send a note to ppc@g.o, sparc@g.o, etc. saying that they might be interested in keywording kdebindings-meta. It's nearly impossibile to use anything different from 3.3.2 anyway since it triggers the infinite upgrade/downgrade loop.
OK, I'm implementing (2).
Added x86 keywords and sent mail to archs.
A week has passed and no keywords in kdebindings-meta... I think we should remove kdebindings now, other arches can keyword kdebindings-meta later if they're still interested.
kdebindings 3.3.0 can't be emerged right now and 3.2.x isn't very useful. There are also no other packages in the tree relying on kdebindings. So there's no point in keeping them around.
kdebindings now removed from portage, and added move kdebindings -> kdebindings-meta.
On non-x86 archs where kdebindings was keyworded, the move instruction will produce unsatisfiable deps in the world file...
If they had kdebindings in their world file, probably they already had some problems (at least the upgrade/downgrade loop). But removing the move instructions is ok for me if it's not safe. If it's better to remove it, just say so.
Then I'll remove it. People who need the bindings (considering that no other ebuild depends on them) will know enough to seek out the new versions for themselves.
Agreed.
