It looks like you have a work around by building against libedit, but linking
to against libreadline. I think this is a big improvement against everything
being broken, but a really _HORRIBLE_ ingenious solution :)
Could we not go back to building against libreadline and reopen the licencing
Hi,
If calling psql as
LD_PRELOAD=/lib/libreadline.so.5 psql
everything works as normal. As that is just usage, not linking, that
isn't covered by the GPL (see the pretext, stating that Activities
other than copying, distribution and modification are not covered by
this License; they are
Andreas Barth [2011-02-13 13:01 +0100]:
If calling psql as
LD_PRELOAD=/lib/libreadline.so.5 psql
everything works as normal. As that is just usage, not linking, that
isn't covered by the GPL
I can't follow this reasoning. LD_PRELOAD invokes the linker (ld.so)
just in by and large the same
* Martin Pitt (mp...@debian.org) [110213 17:51]:
Andreas Barth [2011-02-13 13:01 +0100]:
If calling psql as
LD_PRELOAD=/lib/libreadline.so.5 psql
everything works as normal. As that is just usage, not linking, that
isn't covered by the GPL
I can't follow this reasoning. LD_PRELOAD
Hello Andreas,
Andreas Barth [2011-02-13 19:18 +0100]:
from. derived from happens already if the packages uses .h-files
from the gpl-library, runs the link stage again the so-files during
compilation etc.
So you think linking in the license sense just applies to the time
when we build the
* Martin Pitt (mp...@debian.org) [110213 20:21]:
Andreas Barth [2011-02-13 19:18 +0100]:
from. derived from happens already if the packages uses .h-files
from the gpl-library, runs the link stage again the so-files during
compilation etc.
So you think linking in the license sense just
retitle 608442 use libreadline instead of libedit for psql
reassign 608442 postgresql-common 113
forcemerge 608442 607907 607109 611918
thanks
Thank you Andi for the more detailled explanation!
So here's my plan of record:
* I will continue to build the postgresql-X.Y packages against
7 matches
Mail list logo
