Hi Lumin,
>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. actually I understood this correctly... well there is an etc/profile.d for this purpose I guess >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 ? Don't know... maybe it is not even needed, a manpage might be enough > >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. sure, LD_LIBRARY_PATH is also better if you want to change the library location (I personally use RPATH, but they are fine both) > >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. sure cheers, Gianfranco