Bugzilla Bug 195366

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
:))