Hi Gianfranco Costamagna, On Mon, 2015-08-17 at 08:27 +0000, Gianfranco Costamagna wrote: > yes, exactly the point I had, so somewhere the user should be aware that reporting > the bug on Debian Bug Tracking System is *wrong*. > and here we are: > how do you say that to the user? > You say overriding the env is bad, but you didn't provide (AFAICS) a good way for letting > the user know about the profile I didn't mean "overriding the env is bad". I mean: -> can we directly add ENVs for users? -> how about doing this in wrapper script: sed -i -e "$a\$(cat /usr/share/.../example/profile)" .bashrc -> very bad. Then can ENVs be handled automatically? Then there are 2 things to convey to linuxbrew-wrapper users: * linuxbrew packaging bug is not debian bug but upstream bug, report linuxbrew bug at upstream github. * there's a example profile located at /usr/share/doc/linuxbrew-wrapper/examples/profile and one can simply source it in bashrc/zshrc for the basic linuxbrew utilization. If user installed some libs with linuxbrew, he/she needs to handle BREW_LIB BREW_INCLUDE LD_LIBRARY_PATH ...etc ENVs. And I'm going to state them * before invoking upstream install script * in the manpage which is to be added. Is there better way to tell the 2 points to users ? * postinst ? *.News ? > this is fine, as long as you set RPATH on the linuxbrew packages, or you > LD preload in some way the binary at each run LD_LIBRARY_PATH / RPATH: IMHO LD_LIBRARY_PATH is better, since rpath is a problem on Debian packaging and RPATH info is embedded into ELFs. > Note: I didn't run the code, because I think some discussion is needed, at least on debian-devel to see > other folks's opinions. I think so. however currently this package is not ready to get public attention. At lease I need to compose a manpage to state the main idea of this package. > I know very well the subject, and actually I did something brew similar in my work company, to keep our > installing them in a private location, to avoid messing up with users systems and messing up with different versions > > of our libraries (a customer might do not want to rebuild against a new library version, if the old one > fits the needs for him). > > The problem here is that using non-standard locations is source of troubles, but I see you/brew fixed them > in the proper way (at least the same way I fixed them in my workplace). I'm glad to hear that. > If other DDs gives an ack I'll be happy to finish my review :) OK and thank you :-) -- .''`. Lumin : :' : `. `' `- 638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A
Attachment:
signature.asc
Description: This is a digitally signed message part