pd-zexy compilation improvements

[IOhannes zmölnig]

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)

fmgdft
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100827/35f71db5/attachment.pgp>