Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Giulio,

On 18 May 2016 at 07:15, Giulio Paci  wrote:
> One approach that usually fits my needs is the one proposed by Thibaut 
> Paumard [1], that I am reproposing here with minimal changes:

Thanks for sharing this pretty detailed case. As my issue with
"pythonpy" was way more simpler, I ended up updating the new path in
its bash-completion file[2] (and cleaning it, removing unneeded
entries).

Of course your suggestions are useful for more complex packages and
your contribution here will not be in vain.

Regards,
Tiago.

[1]: https://lists.debian.org/debian-mentors/2012/04/msg00012.html
[2]: 
https://anonscm.debian.org/git/collab-maint/pythonpy.git/tree/debian/patches/0002-fix-bash-completion.patch?id=fb1165d

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Binaries under "/usr/lib/"

[Giulio Paci]

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  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//bin
2) install a small script (possibly named ) in /usr/bin
this script should provide an interface so that calling:
 
will grant that any required variable is set to the right value
and that /usr/lib//bin/ 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/

Re: Binaries under "/usr/lib/"

[Ben Finney]

Tiago Ilieve  writes:

> 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 was looking at § 9.1.1 File System Structure[1] from the Debian
> Policy Manual and it states that the need to put object files,
> internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
> is a requirement - however, it doesn't says how this should be done.

Right. Debian Policy states how things should be; it is not the job of
Policy to say exactly how to implement most policy requirements, because
there must be plenty of room to evolve better solutions.

So, if you want more specifics, you will need to point us to the exact
code base we're discussing so advice can be given in context.

-- 
 \   “People are very open-minded about new things, as long as |
  `\ they're exactly like the old ones.” —Charles F. Kettering |
_o__)  |
Ben Finney

Re: Binaries under "/usr/lib/"

[Tiago Ilieve]

Hi Ben,

On 17 May 2016 at 21:06, Ben Finney  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? I was looking at § 9.1.1 File System Structure[1] from the
Debian Policy Manual and it states that the need to put object files,
internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
is a requirement - however, it doesn't says how this should be done.

So, even appreciating your suggestions, I would like to hear from some
maintainers that are used to do this on their packages. This way we
can possible mix both some battle-tested approaches and your nice tips
as well.

Regards,
Tiago.

[1]: https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Re: Binaries under "/usr/lib/"

[Ben Finney]

Tiago Ilieve  writes:

> Hi Mattia,
>
> (Moving the discussion from BTS to "debian-mentors" mailing list.)
>
> On 15 May 2016 at 20:25, Mattia Rizzolo  wrote:
> > Given that in your case you say the binary is not called by anything
> > else than the application itself, then why keep it in /usr/bin?
>
> As "/usr/lib/" is not part of $PATH, how should we deal with this?
> Patch every process call to the internal binaries in the upstream
> source? Or is there an easier way to work around this?

How many process calls are there? The ideal solution IMO is to:

* 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.

-- 
 \ “Having sex with Rachel is like going to a concert. She yells a |
  `\  lot, and throws frisbees around the room; and when she wants |
_o__)more, she lights a match.” —Steven Wright |
Ben Finney

Binaries under "/usr/lib/"

[Tiago Ilieve]

Hi Mattia,

(Moving the discussion from BTS to "debian-mentors" mailing list.)

On 15 May 2016 at 20:25, Mattia Rizzolo  wrote:
> In this case the binary should go into /usr/lib instead.  That place
> exist exactly for this reason:
> "/usr/lib includes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts"
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

This is interesting, as I wasn't aware of it. Thanks for pointing this
reference.

> Given that in your case you say the binary is not called by anything
> else than the application itself, then why keep it in /usr/bin?

As "/usr/lib/" is not part of $PATH, how should we deal with this?
Patch every process call to the internal binaries in the upstream
source? Or is there an easier way to work around this?

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil