On Mon, Jan 06, 2014 at 10:28:08AM -0800, James Peach wrote: > I'm not very comfortable with this change. I don't think it fixes anything > and I don't think that we have a good idea on how this affects distributions > and end users. I'm perfectly happy with preferring libedit to libreadline, > but I'd like some more information about the impact of removing libreadline.
To my mind if it breaks at compile time it's better than ending up with a binary that has incompatible licenses such as libssl and libreadline. I don't know what's common for checking that licenses are kept in check. But it's a problem faced by quite a lot of software. An example of which is: http://lwn.net/Articles/428111/ With PostgreSQL also linking against readline and openssl in violation. I must admit i don't understand all the complications, but to my mind the less dangerous path is to just not link against GPL libraries for non GPL software, and not take unnecessary risks when libedit can acheive the desired functionality. That said libedit may not be supported everywhere. But if support is not found the code already supports just not supporting advanced line editing / history capabilities, which can be reenabled by adding libedit/libeditline. Ben.
