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
signature.asc
Description: This is a digitally signed message part
