The plan is to have all ebuilds either depend on =x11-libs/gtksourceview-1.8* or =x11-libs/gtksourceview-2* I'll fix our own packages first, make sure it doesn't break anything, then I'll move on to the other packages (CCing their maintainers of course).
just for reference, bug #193195 comment #2
Doesn't really matter, 1.8 is stable on all arches. And technically, 1.90 was using the 2.0 ABI, so just to err on the safe side of things, I'll put 1.8*.
First package (balsa) and I'm already hitting a road block. Output from repoman: DEPEND.badindev 6 mail-client/balsa/balsa-2.3.20.ebuild: alpha(default-linux/alpha/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] mail-client/balsa/balsa-2.3.20.ebuild: x86(default-linux/x86/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] mail-client/balsa/balsa-2.3.16.ebuild: ~alpha(default-linux/alpha/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] mail-client/balsa/balsa-2.3.16.ebuild: ~x86(default-linux/x86/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] mail-client/balsa/balsa-2.3.13.ebuild: alpha(default-linux/alpha/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] mail-client/balsa/balsa-2.3.13.ebuild: x86(default-linux/x86/no-nptl/2.4) ['=x11-libs/gtksourceview-1.8*'] If I put the depend on 1*, it works. Something in the dep list must be masked on those 2 profiles. I'd rather avoid doing the dep on 1*. But then the other option opens a whole can of ugly worms : do we drop gtk support entirely on those 2 profiles (default-linux/{alpha,x86}/no-nptl/2.4) ?
Once 2.16 is gone from the tree, gnome support (not gtk, mind you...) will be dropped for all 2.4 kernel profiles. 2.18 and later need a 2.6 kernel. Since 1.90 was only in the overlay and is now gone, I'd say it's safe to use a 1* dep in these packages...
Done for today : dev-python/gnome-python-desktop app-editors/gedit dev-python/pygtksourceview dev-cpp/libgtksourceviewmm x11-libs/xfc gnome-extra/libgnomedb mail-client/balsa
Done for today : app-editors/amyedit app-editors/conglomerate (this one's gnome's ... who uses that?!) app-editors/katoob app-editors/mlview app-editors/peacock app-editors/tea (note to herd, half of those are ours, the ebuilds are ugly but easy to fix)
Done for today : dev-dotnet/gtksourceview-sharp dev-embedded/gnusim8085 dev-haskell/gtk2hs dev-lang/boo dev-php5/php-gtk dev-ruby/ruby-gtksourceview dev-util/anjuta dev-util/giggle dev-util/portatosourceview gnome-base/gnome net-misc/drivel sci-electronics/oregano And that's the end of the list. Only gobby is left awaiting treatment.
Gobby can handle both for now. It can be improved without blocking :) Fixed
Hmm :) - I had to get the changes reverted in dev-util/portatosourceview, as the new dependency "=x11-libs/gtksourceview-1.8*" is wrong for this package. It now (again) is: >=x11-libs/gtksourceview-1.8.5-r1 <x11-libs/gtksourceview-2.0.0 This is because the package needs at least x11-libs/gtksourceview-1.8.5-r1 (it depends on the gentoo.lang which is included with this gtksourceview version the first time).
Erf, I was planning on asking arches to stabilize this version so that we could get rid of the earlier versions of the 1.8 series. :) But you're right, I should have done it that way. Thanks for fixing it. PS, maybe it's time we used those slotted deps? ...
René, Gilles (eva) pointed out to me why this is wrong. Basically you're putting a blocker on gtksourceview 2.0 which is what we want to avoid. You're going to be forcing your users to choose between Portato and Gnome 2.20. This is why we went with the wildcard dep. I know Portato wants the .lang file but this is a small concession we're going to have to make for now. Since portatosourceview is ~ only, people will get the new gtksourceview anyway. So please change it back :) Thanks
I fixed portatosourceview - made a new release now not depending on the existence of the gentoo.lang. This should fix our both issues ;) ... (But as I don't have access to the tree, I need to wait for my proxy-maintainer :))
