On Fri, Aug 27, 2010 at 12:11:16PM +0200, IOhannes zmölnig wrote:
On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:Hmm. Do we then perhaps need to beware of this for helper tools like lintian and dh_shlibdeps?I actually do not think that dh_shlibdeps has any role here, just mentioning it as an example: For Debian packaging we have a bunch of helper tools used either directly during packaging or during various tests and inspections, which rely on e.g. shared libraries ending in .so and located below /usr/lib. When then unusual things are done, we might want to add hints for such tools to not hide potential problems from them.Or expressed differently: Even if PureData works splendid with its unusual naming, we still might benefit in Debian (and derivatives) from using the classic .so extension if indeed it is technically the same.i think there is no issue here at all. we are talking about "modules" (binaries that can be dlopen()ed).dlopen()ed modules are technically quite the same as shlibs (meaning, the way they are built), but are used in a different way, that makes issues such as installation path and/or rpath irrelevant (at least, as far as i understand it)so from this perspective, we don't have to care about the extension. (i guess this came from my confusing use of "shared library"; sorry for that; anyhow, debian-policy is quite clear that "modules" need not have an .so extension) the other point is of course, whether tools like dh_shlibdeps and dh_strip work correctly. i can only say from experience, that they do. e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped and the package depends on all packages that provide libraries the binary has been dynamically linked to. debian/rules does not extra care of shlibs. so it seems to "just work" i think that changing the default extension of pd-plugins only in Debian, will make things unnecessary complicated, as it would require to patch the module-loader of puredata as well as practically every single build system for externals, only to find ourselves deviant from and incompatible with virtually any other puredata distribution. to sum up, i don't think the gain would outweigh the cost. (esp. since there is currently no real gain, as adhere to the debian-policy and all tools work as expected)
Thanks for the long explanation. I am thrilled to be around such knowledgeable folks here!
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers