repo: https://richardipsum@bitbucket.org/richardipsum/definitions.git ref: baserock/straycat/readline_python head: 33d836cbf27af4be142281d08c3fb02902b7e98c Hey all, This builds cpython with readline. I've built and deployed a base-system-x86_32 and a devel-system-x86_32 and it works well. Initially I tried using the newer readline (6.3) but python wouldn't compile with that, so for now it's using readline 5.2. I think the issue I encountered compiling with 6.3 may have been fixed now [1] so we might want to move to the fixed version.

With chunk splitting etc could we cause this to be present at build but removed from targets? Would things still work? Otherwise the safer option would seem to be to stick with the older version - i expect postgres would work with that version

On Mon, May 19, 2014 at 10:55:09AM +0100, Daniel Silverstone wrote: > On Mon, May 19, 2014 at 10:45:23 +0100, Paul Sherwood wrote: >> With chunk splitting etc could we cause this to be present at build but >> removed from targets? Would things still work? Otherwise the safer >> option would seem to be to stick with the older version - i expect >> postgres would work with that version > > Splitting would result in a number of un-runnable binaries which linked to the > readline library. The older GPLv2 library seems like the right solution if we > wish to keep compatibility with GENIVI. Alternatively, we build readline-less GENIVI but put readline into other systems where the GPL3 licence is not a problem. readline is mainly useful on systems with interactive users, e.g., people who log in via the console or ssh and use the command line: bash, python, postgres, sqlite3, etc. Our morphologies don't currently support doing that very easily: you'd have to fork a lot of things for this. However, we probably should make morphologies powerful enough to be able to express this kind of smallish variation easily.