rpms/geany/devel geany-find-sonames.patch, NONE, 1.1 geany.spec, 1.3, 1.4 geany-dynamic-vte.patch, 1.1, NONE

[Josef Whiter]

> libvte is not a "simple plugin" whose name is libvte.so, but a real
> shared library, whose runtime library carries a versioned name:
> lib*.so.<number>.
>
>   
Sorry I meant that geany treats it as a plugin, not that it is actually 
a "simple plugin."
> Therefore, IMO, this whole approach geany doesn't make sense.
>
> But even if they really want to explicitly dlopen libvte, then the
> search order should start with "most recent version first".
>
> If I were you, I'd kick out all this searching and hard-code the
> libvte.so.<version> available in Fedora (Can be easily done via a
> define), may-be with a fallback to libvte.so (but I would not do so).
>   
Geany has this approach because they do not want to have a dependency on 
libvte, since geany will work perfectly fine without libvte.  This patch 
is what was committed upstream, so I'm simply matching them so geany 
will load vte properly.  When the next version comes out it will look 
exactly like this (unless of course they change something).  If you only 
have vte installed, you will end up opening libvte.so.9, if you have 
vte-devel it will load libvte.so, which will still work fine.  Which is 
more important, matching what upstream has, or changing the order so we 
prefer libvte.so.9?  Thank you,

Josef