Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/2/25 Felipe Sateler <fsateler at debian.org>:
> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler <fsateler at debian.org> wrote:
>> On Sat, Feb 19, 2011 at 17:46, Dan S <danstowell+debmm at gmail.com> wrote:
>>> 2010/10/31 Felipe Sateler <fsateler at debian.org>:
>>>> Package: wnpp
>>>> Severity: wishlist
>>>> Owner: pkg-multimedia-maintainers at lists.alioth.debian.org
>>>>
>>>> * Package name    : supercollider
>>>>  Version         : 3.4
>>>>  Upstream Author : Lots of people
>>>> * URL             : http://supercollider.sourceforge.net
>>>> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>>>>  Programming Lang: C++
>>>>  Description     : A real time audio synthesis programming language
>>>>
>>>> SuperCollider is an environment and programming language for real time
>>>> audio synthesis and algorithmic composition. It provides an interpreted
>>>> object-oriented language which functions as a network client
>>>> to a state of the art, realtime sound synthesis server.
>>>
>>> OK, status of the supercollider packaging. Here's what I wrote on 4th
>>> jan (re a patch to add versioning to the soname):
>>>
>>>> The patch is in, upstream. What's happening right now is we're
>>>> preparing a 3.4.2 release, which will include this patch. (release
>>>> candidate files are at
>>>> <http://sourceforge.net/projects/supercollider/files/Source/3.4.2/>)
>>>>
>>>> The neatest thing is to wait for 3.4.2 official release, then import
>>>> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!
>>>
>>> Since then, there's been some delay in supercolliderland due to
>>> debating garbage-collection issues in the development branch. We can
>>> either wait more, or apply the patch downstream, in which case it
>>> would I think be ready for others to try? What's the next step once
>>> we're OK with the packaging?
>>
>> Since the patch is already applied upstream, and we are likely to wait
>> a while before 3.4.2 is out, it should be OK to apply the patch
>> locally to 3.4.1 for now. Please do that, and update the packaging
>> accordingly.
>
> Ping?

OK I've had a look at this tonight. There is a scons problem, which
lintian handily discovers for me. (Hooray lintian! I think.)

The patched build script creates symlinks such as
libscsynth.so->libscsynth.so.1.0.0. However, when scons is installing,
it doesn't install a symlink but copies the file contents. Therefore
instead of one lib file and one symlink, we get two identical lib
files - and lintian correctly reports this as an error.

I've been trying to find a way to convince scons to do the right
thing. I pushed an experimental branch to the git named
"scons_soversion" where instead of creating a symlink and asking scons
to install it, we add a symlinking command that should run during
installation. The problem is, that scons (v1.2.0) uses python chdir()
when running commands, which jumps it straight out of the DESTDIR and
tries to install in the system /usr/lib rather than the current build
tree. So I can't find a way of getting scons to create the symlink
during the install step AND inside DESTDIR. One or the other but not
both.

If anyone can offer suggestions I'd be grateful.
http://git.debian.org/?p=pkg-multimedia/supercollider.git;a=shortlog;h=refs/heads/scons_soversion

Dan