[arch-general] New PKGBUILD for libtorrent-rasterbar
Hey all, libtorrent-rasterbar is pretty out of date (2 months and 2 package versions), so here's a PKGBUILD for the new version. I bumped the pkgver (obviously), added python to the dependency list since we *ARE* building the python bindings... and I set the package to use the system libgeoip/geoip rather than the one bundled in the libtorrent tarball (which is a new configure option in libtorrent-rasterbar 0.14.6). It also checks out fine with namcap (no warnings or errors) and it compiled perfectly on the i686 box I tested it on. Part of the reason i'd like to see this updated is that Deluge 1.2.0_rc1 is out and myself and probably a few other Arch users would like to use it, but it requires libtorrent-rasterbar >=0.14.5 . The PKGBUILD is attached, but in case it gets filtered out, here's a pastebin link for it: http://dpaste.com/104444/plain/ Thanks in advance for building/uploading, JD
Quick thing to change that i just noticed. The libtorrent-rasterbar.so version was bumped (from libtorrent-rasterbar.so.4 to libtorrent-rasterbar.so.5) and that confuses at the very least Deluge and possibly other clients as well that use the versioned library rather than the plain .so. Perhaps add a symlink in the PKGBUILD to link libtorrent-rasterbar.so.5 to libtorrent-rasterbar.so.4 or libtorrent-rasterbar.so to libtorrent-rasterbar.so.4.
On Thu, Oct 8, 2009 at 2:33 PM, Jeff Horelick <jdhore1@gmail.com> wrote:
Quick thing to change that i just noticed. The libtorrent-rasterbar.so version was bumped (from libtorrent-rasterbar.so.4 to libtorrent-rasterbar.so.5) and that confuses at the very least Deluge and possibly other clients as well that use the versioned library rather than the plain .so. Perhaps add a symlink in the PKGBUILD to link libtorrent-rasterbar.so.5 to libtorrent-rasterbar.so.4 or libtorrent-rasterbar.so to libtorrent-rasterbar.so.4.
That is a bad idea. The soname version changed for a reason. You don't want to give apps expecting version 4 a version 5 library. Instead, all apps that link this library need to be rebuilt.
Normally, i'd agree with you, but in this case, I wouldn't. First off, looking through the changelog and the commits that make up the release, there are really only API additions, not really any API breaks/removals. Second, I compiled/installed Deluge *AFTER* I compiled/installed libtorrent-rasterbar 0.14.6 and it still was looking for libtorrent-rasterbar.so.4 which makes me think lazy/stupid developer. 2009/10/8 Ray Kohler <ataraxia937@gmail.com>
On Thu, Oct 8, 2009 at 2:33 PM, Jeff Horelick <jdhore1@gmail.com> wrote:
Quick thing to change that i just noticed. The libtorrent-rasterbar.so version was bumped (from libtorrent-rasterbar.so.4 to libtorrent-rasterbar.so.5) and that confuses at the very least Deluge and possibly other clients as well that use the versioned library rather than the plain .so. Perhaps add a symlink in the PKGBUILD to link libtorrent-rasterbar.so.5 to libtorrent-rasterbar.so.4 or libtorrent-rasterbar.so to libtorrent-rasterbar.so.4.
That is a bad idea. The soname version changed for a reason. You don't want to give apps expecting version 4 a version 5 library. Instead, all apps that link this library need to be rebuilt.
Ignore the symlinking stuff i said earlier. :P It had that issues because i had the old libtorrent-rasterbar version installed while building the new one and that seems to have confused it. I removed all traces of libtorrent-rasterbar from the system, did a rebuild and everything works fine without any nasty symlinking.
Jeff Horelick wrote:
Hey all,
libtorrent-rasterbar is pretty out of date (2 months and 2 package versions), so here's a PKGBUILD for the new version. I bumped the pkgver (obviously), added python to the dependency list since we *ARE* building the python bindings... Do the python packages need to be depends, or can they just be makedepends? Just curious, I don't use this myself.
T.
participants (3)
-
Jeff Horelick
-
Ray Kohler
-
Tom K