On 16/09/14 12:40, Fernando de Oliveira wrote:
The reason I modified it, was not just because I wanted to. During the discussions (dev and ticket, IIRC), it was mentioned not only once that SQLite should be removed from Tcl, either because we do it with other packages, or because ArchLinux developers do it. Then, I concluded we were facing a bug in BLFS and it should be urgently fixed before the 7.6 release, and used ArchLinux as example. So, it was not a free-and-easy decision, I think. After David (who I much respect and like, and am forever in debt, after he fixed LO) mentioned the problem with that solution, I asked him if other possibilities could be considered. As of writing this message, still got no reply.
The reversion I did yesterday is not my preferred one, just wanted to run out of the problem. But in my particular machines, I will *remove* SQLite from Tcl, because to the best of my knowledge, the own developers fear it and *it is useless*, perhaps something they are developing for future use.
I'm sorry, I didn't realise you were waiting for me to reply, however, I think I still stand by my original recommendation, which is based purely on the recommendation of the developers, and a 'path of least resistance' policy.
I'm not aware of any specifically security-related issues, if sqlite is linked dynamically, however, the flags are different as used by the sqlite extension, and presumably are so for a reason.
Also, I've done a quick 'confidence' test, and the extension seems to work perfectly well (I've only tested it statically linked), either on the command line (sqlite3), or from tclsh. For the former, see the man page for sqlite3, and for the latter, http://www.sqlite.org/tclsqlite.html .
So, AFICS, it just provides a nice, convenient way of using an SQL database from a command script, either bash or tclsh.
Hope this helps, David -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
