Support setting custom lib version suffixes.

[0xd34df00d]

Different distros may wish to set custom library suffixes depending on their own considerations. For example, it may be desirable to have -qt4 and -qt5 suffixes respectively. This PR adds this via a custom CUSTOM_LASTFM_LIB_VERSION_SUFFIX parameter, like this:

cmake -DCUSTOM_LASTFM_LIB_VERSION_SUFFIX="-qt4"

The default behavior isn't changed.

[xhochy]

How will this change in suffix than be propagated to reverse deps?

[0xd34df00d]

@xhochy I would expect distros to provide pkgconfig for respective libraries.

Moreover, opensuse (if I'm not mislead by my opensuse maintainer :)) already packaged liblastfm-1.0.8 with suffixes -qt4 and -qt5 respectively, so this change allows to maintain the same library names.

[xhochy]

As Up&Downstream developer I see this a bit problematic as liblastfm does not provide by default a pkg-config file (yet) and so the reverse dependencies search by library name. E.g. in https://github.com/tomahawk-player/tomahawk/ we search for (lib)lastfm(.so/dll) for Qt4 and (lib)lastfm5(.so/dll) for Qt5, other programs will do this respectively. You will have to patch each of them to pick up the correct shared object.

Adding a pkg-config or a CMakeConfig will make it easier for future releases but reverse dependcies will still have to look for a while for the library name to support older releases.

Not that I oppose this patch but using custom suffixes means a lot of overhead for packages in distros that will depend on liblastfm. Probably it would be better to first include pkg-config and CMakeConfig generation to better handle these suffixes and then let the reverse deps switch to relying on them (and only use the library name as a fallback). This will certainly reduce the number of patches in distros for them.

[0xd34df00d]

As Up&Downstream developer I see this a bit problematic as liblastfm does
not provide by default a pkg-config file (yet) and so the reverse
dependencies search by library name. E.g. in
https://github.com/tomahawk-player/tomahawk/ we search for
(lib)lastfm(.so/dll) for Qt4 and (lib)lastfm5(.so/dll) for Qt5, other
programs will do this respectively. You will have to patch each of them to
pick up the correct shared object.

I search for liblastfm{,-qt4} for Qt4 version and -qt5 in Qt5 version. I
believe I've started using this after consulting with some downstream
packagers about common practices in their distros. Also, in fact, that's
how liblastfm was patched in 1.0.8 in my ebuilds (which I never cared
enough to push to official Gentoo tree though).

Using a custom suffix would allow to gradually switch from any other naming
scheme currently used to the "official" upstream one.

Adding a pkg-config or a CMakeConfig will make it easier for future
releases but reverse dependcies will still have to look for a while for the
library name to support older releases.

Not that I oppose this patch but using custom suffixes means a lot of
overhead for packages in distros that will depend on liblastfm. Probably it
would be better to first include pkg-config and CMakeConfig generation to
better handle these suffixes and then let the reverse deps switch to
relying on them (and only use the library name as a fallback). This will
certainly reduce the number of patches in distros for them.

I perfectly understand your concerns, but please note this is purely
optional, and the default behavior without the custom library suffix is
just the same as it is now.

[xhochy]

On 11/10/14 21:11, Georg Rudoy wrote:

As Up&Downstream developer I see this a bit problematic as liblastfm does
not provide by default a pkg-config file (yet) and so the reverse
dependencies search by library name. E.g. in
https://github.com/tomahawk-player/tomahawk/ we search for
(lib)lastfm(.so/dll) for Qt4 and (lib)lastfm5(.so/dll) for Qt5, other
programs will do this respectively. You will have to patch each of them to
pick up the correct shared object.

I search for liblastfm{,-qt4} for Qt4 version and -qt5 in Qt5 version. I
believe I've started using this after consulting with some downstream
packagers about common practices in their distros. Also, in fact, that's
how liblastfm was patched in 1.0.8 in my ebuilds (which I never cared
enough to push to official Gentoo tree though).

Using a custom suffix would allow to gradually switch from any other naming
scheme currently used to the "official" upstream one.

From my own Gentoo experience I can tell that you will most likely not
get any changes merged that require reverse dependencies to be patched
if everything would work with the renaming. If some distributions like
to have their suffixes different to the upstream naming they are free to
do this but must also be prepared for the additional work to patch the
reverse dependencies.

As already mentioned: The better solution here would be to add also
pkg-config/CMakeConfig files upstream.

Furthermore: Upstream your distribution patches as early as possible to
prevent such situations (with e.g. different namings) ;)

Adding a pkg-config or a CMakeConfig will make it easier for future
releases but reverse dependcies will still have to look for a while
for the
library name to support older releases.

Not that I oppose this patch but using custom suffixes means a lot of
overhead for packages in distros that will depend on liblastfm.
Probably it
would be better to first include pkg-config and CMakeConfig generation to
better handle these suffixes and then let the reverse deps switch to
relying on them (and only use the library name as a fallback). This will
certainly reduce the number of patches in distros for them.

I perfectly understand your concerns, but please note this is purely
optional, and the default behavior without the custom library suffix is
just the same as it is now.

Sure this is optional and I'm not speaking here against merging it but
advise you to be careful about the implications of using it ;)

—
Reply to this email directly or view it on GitHub
#28 (comment).

[dschmidt]

Is this still desired? We have complete "coinstall" support by now.

[ben-xo]

Unsure if this patch is still relevant?

It's a very simple looking patch, so I can't see it hurting, but further opinions welcome