On 15-09-2014 22:55, Ken Moffat wrote:
> On Mon, Sep 15, 2014 at 08:17:25PM -0500, Bruce Dubbs wrote:
>>
>> The issue is that if sqlite changes, then it may break tcl.  Using a static
>> library avoids that.  On the other hand, if there is a problem with the
>> static library, then it is tcl's job to fix it.  There are pros and cons for
>> both methods and indeed we generally like to use external shared libraries.
>> However in this case, there have been so many problems, I'd prefer to go
>> with static libraries in this case.
>>
> 
>  In this case, I think it is unlikely that sqlite will break tcl.
> But it was fun removing the earlier change from my own scripts, and
> I do not particularly want to repeat that fun.
> 
>  And perhaps we are getting a little too free-and-easy with what
> goes into 7.6 - it is good to know of this dependency, but as you
> say there are pros and cons.

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.

-- 
[]s,
Fernando
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to