Tiny Core Extensions > TCE Talk
New package manager
CNK:
--- Quote ---I can go back and update the .info file to match what TC requires. Is there a template somewhere to use by chance?
--- End quote ---
This is the example I follow. Also the submitqc script in submitqc.tcz checks the info file for wrong or missing fields, among other things.
--- Quote ---In regards to the compatibility with the existing tools and optional dependencies, I can understand your request. But that functionality isn't present, so there's nothing to be compatible with.
--- End quote ---
I was more concerned that like with the info file you'd submit extensions with dep files in a format that breaks the regular tce* tools. If you have something like separate "extension.tcz.dep.opt" files then that might work better, but otherwise I'd hope the tce* tools get support added for any new formatting features before they're used in the repo.
--- Quote ---To quickly go back to the start of this additional conversation... Part of the reason pax can not search packages is because it looked like it just pulled down the files ondemand. Based on our conversation, it appears that I was right.
--- End quote ---
Yes, but I'm not sure why you said Debian's package system is more "server-side" than on TC. Debian also downloads a full package list to search locally, and it downloads the description and dependency info equivalent to the info and dep files for all packages too. Debian do have a web interface that allows searching in a web browser, but apt-get and other package managers I've used there all locally search the downloaded package lists.
Rich:
Hi wysiwyg
--- Quote from: wysiwyg on January 28, 2026, 09:24:22 PM --- ... So then it basically does download the entire repo's worth of non-software package files. ...
--- End quote ---
I'm working from memory here, and referring to the Apps GUI:
--- Code: ---These get loaded for browsing/installing extensions:
info.lst Used to populate the left window of Apps
provides.db Used to populate the Files tab of Apps,
sizelist Used when populating the Size tab of Apps.
These get loaded for functions under Apps->Maintenance:
dep.db.gz Dependencies And Deletions, Check Onboot Unneeded, Check for Orphans
md5.db.gz Md5 checking, Check for Updates
Used in Search options:
provides.db Search for extensions by provided file
tags.db.gz Search for extensions by listed tags
--- End code ---
--- Quote --- ... First, there is a pinned post at the top of this board saying not to abuse the bandwidth that is generously being donated to the project. ...
--- End quote ---
I'm not sure which post you are referring to, but that was likely in response
to individuals downloading entire repos.
--- Quote --- ... Even with using zsync, that would still fall under that category - at least in my eyes. Without putting these files somewhere that they get saved, they would have to be re-downloaded every time a device reboots. ...
--- End quote ---
A reboot does not automatically result in a re-download.
sizelist and tags.db are in /tmp , so they would get re-downloaded if they're needed.
dep.db and provides.db are in the tce directory, so they are persistent.
--- Quote --- ... TC takes great strides at being as small as possible, yet to perform this task with the existing package manager, it has to bloat the system with the entire software library.
--- End quote ---
I don't understand what you are trying to say there.
How are we bloating the system with the entire software library?
wysiwyg:
--- Quote from: patrikg on January 29, 2026, 01:47:42 AM ---This topic has being discussed before, how our package manager deal with how to determine what files is in what package ?
I suggested a SQLite solution, so you could also add more fields like description size and so on.
But i see the point of what TC is all about, simple and small. And not lot of dependencies, in this SQLite.
Let me see on my computer if i have the POC saved ?
--- Code: ---$ cat make.sh
#!/bin/sh
sqlite3 files.db "CREATE TABLE IF NOT EXISTS tcz_files (name TEXT NOT NULL,file TEXT NOT NULL);"
for filename in $(ls *.tcz)
do
tczfile=$filename;for file in $(unsquashfs -lc $tczfile); do sqlite3 files.db "INSERT INTO tcz_files ( NAME , FILE ) VALUES ( '$tczfile' , '$(basename $file)' );" ; done
done
--- End code ---
--- Code: ---$ cat search.sh
#!/bin/sh
sqlite3 -cmd ".timer on" -box files.db <<< "SELECT name as Package, file as File FROM tcz_files WHERE file LIKE '%$1%';"
--- End code ---
Maybe you could steal my POC and make something about it.
Happy hacking :)
--- End quote ---
Hey Patrikg!
Thanks for the code snippets! :) It looks like you are trying to use sqlite for a local repository on each client. I'm actually trying to get an online solution for searching non-local files. With the files that are already downloaded, they can have their corresponding .info files parsed - at least with pax. The tce-* scripts require the downloading of the entire non-software package files. This could be useful for offline devices, but then they couldn't download anything anyways making this a non-point. The vast majority of devices are connected to the internet making this wasteful. An online search takes zero space on your local storage while providing you the results you seek, for either local or non-local packages.
wysiwyg:
--- Quote from: CNK on January 29, 2026, 02:47:20 AM ---
--- Quote ---I can go back and update the .info file to match what TC requires. Is there a template somewhere to use by chance?
--- End quote ---
This is the example I follow. Also the submitqc script in submitqc.tcz checks the info file for wrong or missing fields, among other things.
--- End quote ---
Awesome! I'll grab that and adjust my .info files to match.
--- Quote from: CNK on January 29, 2026, 02:47:20 AM ---
--- Quote ---In regards to the compatibility with the existing tools and optional dependencies, I can understand your request. But that functionality isn't present, so there's nothing to be compatible with.
--- End quote ---
I was more concerned that like with the info file you'd submit extensions with dep files in a format that breaks the regular tce* tools. If you have something like separate "extension.tcz.dep.opt" files then that might work better, but otherwise I'd hope the tce* tools get support added for any new formatting features before they're used in the repo.
--- End quote ---
Gotcha! I don't think you'd have to worry about this because it would take modifying the .dep files for various packages in the repo, of which I have no control over. Nor would I want to do that without approval anyways. But, if that functionality was added into the tce-* scripts from pax, I'd suggest to adopt the other forms of entries to those files as well (versioning, copying specific files from the package, etc).
--- Quote from: CNK on January 29, 2026, 02:47:20 AM ---
--- Quote ---To quickly go back to the start of this additional conversation... Part of the reason pax can not search packages is because it looked like it just pulled down the files ondemand. Based on our conversation, it appears that I was right.
--- End quote ---
Yes, but I'm not sure why you said Debian's package system is more "server-side" than on TC. Debian also downloads a full package list to search locally, and it downloads the description and dependency info equivalent to the info and dep files for all packages too. Debian do have a web interface that allows searching in a web browser, but apt-get and other package managers I've used there all locally search the downloaded package lists.
--- End quote ---
Hmmm can you point to where this list is? I checked /var/lib/apt and the files in there only contain hashes to (past?) files, or brief info for installed packages. I couldn't find anything where the entire repo's package listing is stored locally. And yes, this is the equivalent to .info and .dep files for already downloaded packages being on the device. This is not what I'm referring to. pax can already parse those files for local searches. For example, if a user wants to know what database servers are available in the online repo, those files are no good. The current setup that TC has is to download the entire repo's worth of information files and search locally. An online search would be much more efficient in terms of bandwidth and storage, right?
wysiwyg:
Hey Rich, thanks for the reply!
--- Quote from: Rich on January 29, 2026, 10:03:43 AM ---
--- Quote --- ... First, there is a pinned post at the top of this board saying not to abuse the bandwidth that is generously being donated to the project. ...
--- End quote ---
I'm not sure which post you are referring to, but that was likely in response
to individuals downloading entire repos.
--- End quote ---
Yes, that was the post that I was referring to. But wouldn't the partial download of the entire repo also fall under that category? If the same results can be achieved without downloading anything, isn't that the most efficient use of bandwidth that is being donated?
--- Quote from: Rich on January 29, 2026, 10:03:43 AM ---
--- Quote --- ... Even with using zsync, that would still fall under that category - at least in my eyes. Without putting these files somewhere that they get saved, they would have to be re-downloaded every time a device reboots. ...
--- End quote ---
A reboot does not automatically result in a re-download.
sizelist and tags.db are in /tmp , so they would get re-downloaded if they're needed.
dep.db and provides.db are in the tce directory, so they are persistent.
--- End quote ---
I understand. I wasn't sure where the files were being placed. It was just an observation based on the non-permanent nature of parts of the OS.
--- Quote from: Rich on January 29, 2026, 10:03:43 AM ---
--- Quote --- ... TC takes great strides at being as small as possible, yet to perform this task with the existing package manager, it has to bloat the system with the entire software library.
--- End quote ---
I don't understand what you are trying to say there.
How are we bloating the system with the entire software library?
--- End quote ---
So if TC optimizes their packages during compile to be smaller in size (which they do) to shave off bytes per binary, I'd say that's going through effort to have the smallest distro possible. If a normal user that uses the GUI for the tce-* scripts does any type of search, they are automatically downloading entire parts of the repo. If it doesn't matter in that instance, why go through the efforts elsewhere to make this as small as possible?
If the search abilities for packages, whether for local or remote, can be accomplished with the same results, and one doesn't add anything to your storage (also saving donated bandwidth) vs one that does, wouldn't that fall in line with other aspects? Let alone just being a more efficient system overall?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version