SuperCollider package

[Dan S]

2010/11/3 Felipe Sateler <fsateler at debian.org>:
> On Wed, Nov 3, 2010 at 06:32, Dan S <danstowell+debmm at gmail.com> wrote:
>> 2010/11/3 Felipe Sateler <fsateler at debian.org>:
>>> 2010/11/2 Dan S <danstowell+debmm at gmail.com>:
>>>> 2010/10/31 Felipe Sateler <fsateler at debian.org>:
>>>>> Артём, you are CCed because I don't know if you are subscribed to the list.
>>>>>
>>>>> On Sat, Oct 16, 2010 at 11:09, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>>>
>>>>>> 2010/10/6 Felipe Sateler <fsateler at debian.org>:
>>>>>> > Hi all, (Dan CCed because I'm not sure if you are subscribed to the list)
>>>>>> >
>>>>>> > I managed to take a few minutes to take a look at the package and it is
>>>>>> > not in a very good shape (it was still using simple-patchsys!). I have
>>>>>> > worked a bit on it, but it still has a long way to go. I will try to
>>>>>> > work on it during this week, I think I can find one hour or two.
>>>>>> >
>>>>>> > Dan, as you are part of upstream, could you comment on the patches
>>>>>> > included in the packaging? I can see they are in upstream svn ubuntu
>>>>>> > packaging module, with yourself as last commiter on most of them. They
>>>>>> > are older than the latest sc release, though.
>>>>>>
>>>>>> Hi - sorry for slow reply, I missed this thread. Most of the patches
>>>>>> are by other people but I will try to comment:
>>>>>>
>>>>>> 02_disable_elisp_compilation.diff
>>>>>>  - not sure I'm afraid, it's connected with the emacs sc3 mode, which
>>>>>> I don't use. Looks like it might disable something from running simply
>>>>>> because the build machine isn't the target machine.
>>>>>>
>>>>>> 03_fix_elisp_install_path.diff
>>>>>>  - another emacs mode thing, not sure.
>>>>>
>>>>> Does anyone use emacs and can comment on wether this should be applied
>>>>> upstream? The patch changes the elisp install path from
>>>>> /usr/share/emacs/site-lisp to /usr/share/emacs/site-lisp/supercollider
>>>>>
>>>>>>
>>>>>> 06_deb_scvim.diff
>>>>>>  - build machine != target machine so don't error out if no ruby executable
>>>>>>
>>>>>> 07_deb_sced.diff
>>>>>>  - build machine != target machine so don't modify machine's mime database
>>>>>
>>>>> Dan, can you comment on whether these can be upstreamed? I don't see
>>>>> why they should be debian-specific.
>>>>
>>>> Right, that makes sense. I've had a look at the scons scripts and not
>>>> been able to integrate them in neatly (was hoping to add a nice option
>>>> for not-installing-here - if anyone has the scons chops to suggest
>>>> something then please do, I'd be grateful.)
>>>
>>> Can't do it, at least for the time being.
>>
>> np. In the medium-term, upstream is moving from scons to cmake; the
>> build scripts will hopefully be less quirky!
>
> cmake does this automatically: rpath is used when building, but it is
> stripped at install time.
>
>>
>>
>>>> FYI, supercollider 3.4.1 (bugfix release) has just been agreed, so is
>>>> likely to come out very very soon without any further upstreaming. I
>>>> hope that doesn't get in the way of debianising... would these patches
>>>> be considered blocking issues, do you think?
>>>
>>> I'm not quite sure what you mean. If you mean that the patches are not
>>> likely to be upstreamed before that, then it is no problem, we can
>>> continue with the patches.
>>
>> Yes, that's what I meant, thanks. Just making sure I get the flow
>> right, don't miss out anything I should be doing.
>
> Don't worry.
>
> By the way, the package needs to get the SONAME issue right, does
> upstream have a stance on this?

We have had a long-term stable ABI and that's generally the
philosophy, but we agreed that we should version the lib names anyway.
One of the other devs has a patch for it that they're digging out...

Dan