On Mon, 2009-10-05 at 13:12 +1100, Matthew Palmer wrote:
> On Mon, Oct 05, 2009 at 03:43:22AM +0200, Jarom?r Mike? wrote:
> > > Od: Jarom?r Mike? <firstname.lastname@example.org>
> > JM> > I did it, but it breaks functionality ... there exist also symlinks with
> > JM> same name and in same location.
> > JM> > usr/bin/lv2rack
> > JM> > usr/bin/zynjacku
> > JM> > usr/bin/zynspect
> > JM> > ------
> > JM> > usr/bin/lv2rack.py
> > JM> > usr/bin/zynjacku.py
> > JM> > usr/bin/zynspect.py
> > CLJ> > Hmmm what about remove these symlink first and then remove suffix?
> > CLJ> > I am going to try it.
> > CLJ> How about just mv /usr/bin/lv2rack.py /usr/bin/lv2rack and so on?
> > JM> nice solution ... but there is anyway something broken.
> > JM> This package actually contains two commands you can call from CLI zynjacku and
> > JM> lv2rack.
> > JM> When I remove ".py" suffixes lv2rack stop works ... zynjacku is fine.
> > JM> Without removing ".py" suffixes both work fine.
> > JM> I have to investigate it more.
> > BTW: error message for lv2rack is:
> > -------
> > $ lv2rack
> > Traceback (most recent call last):
> > File "/usr/bin/lv2rack", line 52, in <module>
> > import zynjacku as zynjacku
> > ------
> So someone's using a single file as both a library and a stand-alone
> program. Damned silly idea. Stick zynjacku.py in a proper library path
> somewhere, and write a little shim wrapper to stick in /usr/bin that calls
> zynjacku as it expects to be called.
Involving upstream is always a good idea in these cases, since you will
be creating a divergence from pristine upstream source.
Also, isn't it possible to install zynjacku.py in site-packages (before
calling dh_pysupport, of course) and symlinking it from /usr/bin