Re: Bug#262181: beast: missing essential binaries in /usr/bin/ (fwd)

[Tim Janik <timj gtk org>]

> From: Sam Hocevar <sam zoy org>
> Subject: Re: Bug#262181: beast: missing essential binaries in /usr/bin/

> On Fri, Jul 30, 2004, Tim Janik wrote:
> > Package: beast
> > Severity: grave
> > Justification: renders package unusable
>
>    I'll revert the change, but this definitely does not render the
> package unusable.

i called it unusable because essential package components failed to
work, i.e. the scripts.

> > however beast depends on its binaries to sit in ${prefix}/bin:
> > - users may bypass the nice-level wrappers when starting beast or bsesh to:
> >   a) allow non-priviledged synthesis rendering (especially important for
> >      non-realtime rendering scenarios)
> >   b) allow debugging (beast is still pre-1.0, so debugging is an
> >      expected usage scenario)
>
>    This can still be performed by launching /usr/lib/beast/beast-0.6.1
> for instance. As for allowing non-priviledged synthesis rendering, this
> should really be a commandline flag and not a whole extra binary to
> launch.

correct. adding -n <nicelevel> and -N to turn of nicing to the beast and bsesh
launchers is now on the TODO list.

> > - plugin and script registration which are essential to proper operation and
> >   usage of .bse files (beasts native file format) depend on all executables
> >   to reside in ${prefix}/bin. since the move they fail to register and
> >   execute.
>
>    I did not know that, but this behaviour seems really broken to me. I
> would expect for instance to be able to build my own version of beast
> (with different compilation flags) without installing it,

that won't work with beast like with a lot of other programs (e.g. gimp),
it requirtes a successfull installation ofr proper operation (FAQ 1.7).

> or installing
> it in my home directory with a different DESTDIR, and still use the
> system's plugins.

installing in your home directory does work. i'm not sure what's with
the $DESTDIR changes though, if you can change that variable on each
installation, beast doesn't get a change to construct $DESTDIR/pluginpath
at runtime.
using the system's plugins most likely wouldn't work anyway, as there are
frequent binary and source incompatible changes in libbse, so that the
required .so version number is even part of the plugin installation paths.
if you really intend to load plugins from a nonstandard location, you
can either put them into ~/beast/plugins or alter the preferences.

> > if the versioned binaries were to be moved at all, that'd be a decision
> > which has to be made and needs extra support *upstream*.
>
>    My main concern was unnecessary bloating of the list of binaries in
> PATH, and user confusion. You cannot expect the average user to know the
> difference between beast and beast-0.6.1 (and this person will usually
> launch beast through an entry in the menu system anyway), and a more
> experienced user can find the binaries in /usr/lib/beast/.

the menu entries and mime handlers are registered for just beast
and bsesh.

>    I am personally irritated with this extra entry when cycling through
> binaries starting with "be" in my shell, but that's probably just my
> problem.

the added versioned binaries are pretty similar to what gcc<tab> or
automake<tab> gives you. i guess sfidl should be versioned as well
though... <sigh, off editing TODO again>

>
> Regards,
> Sam.

---
ciaoTJ