Hello,

> On 3 Apr 2022, at 15:49, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> hello *,
> 
> looking at
> 
>>> +	/usr/lib/tcl8/8.4/platform-1.0.14.tm \
>>> +	/usr/lib/tcl8/8.4/platform-1.0.15.tm \
>>> +	/usr/lib/tcl8/8.5/msgcat-1.6.0.tm \
>>> +	/usr/lib/tcl8/8.5/tcltest-2.4.0.tm \
>>> +	/usr/lib/tcl8/8.6/http-2.8.9.tm \
>>> +	/usr/lib/tcl8/8.6/tdbc/sqlite3-1.0.4.tm \
>>> +	/usr/lib/tcl8/8.6/tdbc/sqlite3-1.1.2.tm \
>> 
>> Why do we even ship tcl? Is anything reliant on this?
> 
> in particular and the tcl rootfile in general, I would like to bring your question up again.

TCL is required at build time for various packages. However, at runtime there is one:

root(a)michael:/build/ipfire-2.x# grep -r "^#\!.*tcl" build
build/usr/sbin/usb_modeswitch_dispatcher:#!/usr/bin/tclsh
grep: build/usr/share/misc/magic.mgc: binary file matches

That means we will need to ship tcl.

> This is especially because the current tcl rootfile ships file I definitely expect in the
> sqlite territory, not here:
> 
>> #usr/lib/sqlite3.36.0
>> usr/lib/sqlite3.36.0/libsqlite3.36.0.so
>> usr/lib/sqlite3.36.0/pkgIndex.tcl

Since that script is not using sqlite, you can disable building both modules.

> To my understanding, this makes it hard to understand if the sqlite version carried out
> via tcl takes precedence, or if the _actual_ sqlite version is effective.

They serve different purposes.

> Unless anybody has an idea why we actually need to ship tcl, I would like to try out what
> happens if we don't. :-)

See above.

> Thanks, and best regards,
> Peter Müller

-Michael