OPUS runs in a debian linux environment too. To install:
alien opus-0.65-339-2008-06-27.i386.rpm
creates a deb package. This can be installed using
dpkg -i dpkg -i opus_0.65-340_i386.deb
It may be, that libraries have to be installed.
To point at the opus libraries:
lddconfig /usr/lib/opus/bin
Introduce a newgroup called opus.
opus has to be started as in group opus and has to have write permissions to the current directory (?) or its bin directory.
I couldn't find the command line argument for changing this directory. The former version had a script which took care of this.
It does however start smoothly.
Mathias
Installation in Debian (testing)
Moderators: Andreas Mohr, rah
-
Andreas Mohr
- Posts: 29
- Joined: Mon Jun 30, 2008 4:50 pm
Hello,
very nice to hear that Debian testing actually satisfies all library dependencies of the current OPUS build! (I haven't done a test run on Debian testing in recent times myself, thus it's useful input)
In fact it's not package format differences which cause many distribution problems, it's library version incompatibilities. Or, to put it differently, one cannot generally say that a package "works on Debian" or some other distribution, but rather always has to take the specific version (age!) of the distribution into account.
E.g. on Ubuntu 7.10 and openSUSE 10.3 the current OPUS build fails to launch due to a memory corruption bug (annoying incompatibility with newer GTK library versions as used by these distributions) in wxWidgets 2.6.4. This should be correctable (and thus available in the next OPUS test package) with a small hotfix to wxWidgets, however.
The command to use is named "ldconfig" instead of "lddconfig", however that's actually not necessary when using the launcher script as recommended, which is contained in opus-0.65-339-2008-06-27.i386.rpm (installed as usr/bin/startopus.bash).
Possibly something goes wrong during alien package conversion here and thus startopus.bash was missing on the Debian installation?
In any case, many proprietary or very generically deployed applications such as Firefox, OpenOffice, Acrobat, RealPlayer etc. usually need to do a lot of custom setup / tweaks (set up library paths, do permission checks, ...), thus using their specific launcher script (startopus.bash in the case of OPUS) is strongly recommended, to not get out of touch with the official way to run the application.
I'll try to make infrastructure changes to make sure people always know to use startopus.bash first.
Thank you for your detailed report!
very nice to hear that Debian testing actually satisfies all library dependencies of the current OPUS build! (I haven't done a test run on Debian testing in recent times myself, thus it's useful input)
In fact it's not package format differences which cause many distribution problems, it's library version incompatibilities. Or, to put it differently, one cannot generally say that a package "works on Debian" or some other distribution, but rather always has to take the specific version (age!) of the distribution into account.
E.g. on Ubuntu 7.10 and openSUSE 10.3 the current OPUS build fails to launch due to a memory corruption bug (annoying incompatibility with newer GTK library versions as used by these distributions) in wxWidgets 2.6.4. This should be correctable (and thus available in the next OPUS test package) with a small hotfix to wxWidgets, however.
The command to use is named "ldconfig" instead of "lddconfig", however that's actually not necessary when using the launcher script as recommended, which is contained in opus-0.65-339-2008-06-27.i386.rpm (installed as usr/bin/startopus.bash).
Possibly something goes wrong during alien package conversion here and thus startopus.bash was missing on the Debian installation?
In any case, many proprietary or very generically deployed applications such as Firefox, OpenOffice, Acrobat, RealPlayer etc. usually need to do a lot of custom setup / tweaks (set up library paths, do permission checks, ...), thus using their specific launcher script (startopus.bash in the case of OPUS) is strongly recommended, to not get out of touch with the official way to run the application.
I'll try to make infrastructure changes to make sure people always know to use startopus.bash first.
Thank you for your detailed report!