Re: Binaries under "/usr/lib/"
Giulio, On 18 May 2016 at 07:15, Giulio Paciwrote: > 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/"
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 Finneywrote: >>> 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/"
Tiago Ilievewrites: > 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/"
Hi Ben, On 17 May 2016 at 21:06, Ben Finneywrote: > 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/"
Tiago Ilievewrites: > 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/"
Hi Mattia, (Moving the discussion from BTS to "debian-mentors" mailing list.) On 15 May 2016 at 20:25, Mattia Rizzolowrote: > 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