Re: Binaries under "/usr/lib/"
Hi all,
On 18/05/2016 11:48, Ben Finney wrote:
> On 18/05/2016 10:21, Tiago Ilieve wrote:
>> On 17 May 2016 at 21:06, Ben Finney <ben+debian@benfinney.id.au> wrote:
>>> How many process calls are there? The ideal solution IMO is to:
>> Not much of them. In my case, there's just one. I was thinking about a
>> corner case, where there would be multiple process calls, possible
>> making a patch like this somewhat hard to maintain.
>>> * Make the location of application-private binaries configurable at
>>> build time, with a simple one-point-of-truth (e.g. a Makefile
>>> variable).
>>>
>>> * Patch every call to those application-private binaries to use the
>>> configured location.
>>>
>>> * Submit that patch upstream, explaining why it's superior behaviour.
>>>
>>> * Maintain the patch in Debian for the (short?) time while upstream
>>> incorporates the patch.
>> Thanks for your input. I like your suggestions, as they look pretty
>> straightforward, but this is how this is being done for other
>> packages?
>
> Differently, depending on the state of upstream.
I agree with Ben, that it depends on the package.
One approach that usually fits my needs is the one proposed by Thibaut Paumard [1], that I am reproposing here with minimal changes:
1) install the binaries with the original names into /usr/lib/<package>/bin
2) install a small script (possibly named <package>) in /usr/bin
this script should provide an interface so that calling:
<package> <binary>
will grant that any required variable is set to the right value
and that /usr/lib/<package>/bin/<binary> is executed; it is also
possible to drop extensions in the new interface;
3) ideally add "help" and "path" command, in order to simplify the life
of the users.
This approach works well also in case of binary names conflicts, is usually not invasive and allows smooth transitions to the new approach.
For an example you can see irstlm [2]. I think the example is nice as:
- irstlm has many scripts with extensions that people are using in their own scripts;
- it has a "dict" command (so we have a nice conflict with a famous tool);
- recently upstream introduced "plsa" and "plsa.sh" commands, so, after extension removal it has a collision with itself;
- there are "compile-lm" and "score-lm" commands that are very likely to conflicts with many other frameworks in this field;
- I provided a bash-autocompletion file for it.
Bests,
Giulio
[1] https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2] https://anonscm.debian.org/git/debian-science/packages/irstlm.git/
Reply to: