Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: sankarv on December 03, 2008, 02:22:37 AM
-
It would be nice to have a detailed howto for TCE packaging or creating TCE/TCZ packages frm source or binaries of apps.
-
clivesay is working on the docs; however if you're in a hurry, the quick descriptions:
tce - a tarball, unpacked into /
tcz - compressed, read-only loop mount, either zisofs or cramfs supported in the base, files symlinked to /
-
hi thanks for the reply :)
-
Until the docs are available, would someone be willing to post what is necessary to view the contents of and create a tcz package?
I assume that once you have the directory structure built, creation would be similar to the process of creating a cloop...in other words, a single command can be run while in or next to the app directory to wrap it up. Understanding deps would be good, too, but I don't know if I'll need that info right away.
Viewing or extracting the contents is something I think is more important with tcz than with DSL's uci, since uci is easy to find in /opt/app after mounting.
-
There's the script tce2tcz - does that help?
-
Tczs are mounted in /tmp/tcloop, and the contents of each tcz is viewable there.
Creating a tcz manually is done something like this:
cramfs:
mkdir pkg
tar xzvf extension.tce -C pkg
mkfs.cramfs pkg extension.tcz
Been a little while since I used zisofs, but the commands are in the tce2tcz script and I am on a Windows machine.
-
Juanito & Jason: Yes, that's exactly the info I was hoping for.
Thank you very much.
One more thing, though...is there an "uncram" command that will extract the contents directly, so I can view it without mounting?
-
Nope, only for ziso you can use isoinfo, no tool for cramfs.
-
Ok, thanks. So that's one benefit to using ziso over cramfs. Any other pros/cons you can mention to help me decide which route to take?
-
There are limitations on cramfs, see the .info. (could increase the size restrictions, but would mean hacking the kernel afaik)
From what I have seen, cramfs produces smaller files. From what I have read, cramfs is faster in terms of access.
-
One more thing. The tcz extension supports a user.tar.gz like the .uci did. The files in the user.tar.gz can go anywhere in the filesystem, and it resides in the base directory of the tcz. This is useful for configuration files and scripts that do not take up much RAM space and need to be remain writable. Kernel modules, libraries and binaries do quite well existing as symlinks with the exception of the alsa modules for a reason unknown.
A simple way of making a user.tar.gz would go like this. Say a package has the files /usr/local/bin/app and /usr/local/etc/config. With the package untarred into a a directory named work, create a directory named user/usr/local/etc and move the config file into it. Then at the command prompt:
# cd user
# find . -not -type d >/tmp/list
# tar -T /tmp/list -czvf /pathto/work/user.tar.gz
Then make the tcz package out of the work directory as usual. The config file will get installed into the system as if it were a tce while the rest of the tcz installs as usual.
-
Next questions.....
Is there any benefit to combining multiple extensions into one package? Does it use any less resources or load time, or would it only give me less clutter?
If my extensions were combined would tcz, tczl, and tczm need to be kept as three separate packages?
Can /home/tc/* amd /opt/* files be loaded as an extension rather than from a backup or user.tar.gz?
I did /opt files that way in DSL to prevent having to write a backup every time I shutdown.
-
I did build a large extension of all my favorite apps and call it Desktopextension.tczlm. With tczlm the menu entries of your multiple apps all get loaded as well as ldconfig and depmod are invoked. I think it mainly reduces clutter rather than speeding up performance.
tcz, tczl and tczm packages combined together could be named tczlm and have the same effect without the need to split the extensions.
As far as I know any files can be loaded as an extension with the same effect as using a backup, but a backup allows easier saving of the changes to those files. User.tar.gz is what one would use in a submittable extension though for real files in a tcz. But those files could be made into a tce and listed as a dependency with the same effect, but user.tar.gz keeps it cleaner.
Hope this answers some of your questions.
JW
-
Thanks. That last question was asked mainly to help me decide what is best done by remastering and what would be best left to a persistent home. I'm thinking of a persistent home as I do with DSL, but I need to have reiserfs support before the home partition is loaded (I share many of the same files between all my distos, and it's already reiser). So the reiser module will probably be added to a remastered base. My typical behavior is after all the system files are edited to my liking, the only files that change are in $HOME, so it would be pointless to use backup/restore if I have a persistent home. As a replacement for restore, I can add/modify files to /opt from an extension. I'm realizing now that I'm rambling about things that don't really have any bearing on this thread....
guess I'll just say thanks again and be done with it =o)
-
I think it mainly reduces clutter rather than speeding up performance
After adding a dozen or so extensions to my tce directory, I did notice something that bothered me. It wasn't a decrease in performance after the system loaded, but a severe increase in the time it takes to get to the desktop. Just loading the extensions takes twice as long as the entire boot time without the extensions.
I'm thinking now about limiting my system to one or two extensions, and permanently installing my applications onto a harddrive or pendrive.
-
The PPI is basically the installation you are mentioning. It does not require reloading extensions with each boot. Not all extensions support this at this time, though it is in the works to have as many as possible. Essentially this method is a partial hard drive installation. The compile tools will most surely always be installed into the base system because of their close relationship to the libs that are in the base. Therefore they would be the few extensions that would have to be loaded with each boot.
-
I was thinking of this while posting, but wasn't sure if PPI was what I was thinking it was.
As for the compile extension, I have no issue with loading it while I get my system set up....after that I can move it to optional or elsewhere and just load it manually when I want to build something new.
My main concern is with my harddrive setup. As I'd mentioned before, all of my persistent data is stored on a reiser partition. At this point I haven't looked into tc-config enough to learn whether a ppi and/or persistent home can be used on reiser unless I put the reiserfs module (currently being loaded from filesystems-2.6.26.tczm) into a remastered tinycore. I'll get to this in time, but I've just been fooling around so far.