Hey nick65go, thanks for adding to the conversation!
looking into https://github.com/cliquesoft/pax/blob/main/bin/pax it seams it is a /bin/sh script, which is OK.
- An 'html' output option: it needs a "small browser" to see this output (you can be inspired by how fluff.tcz shows its help)
- A graphical interface: FLTK is in the base. [not GTK1/2/3 neither QT4/5/6. nor Xdialog when Wayland is the future].
As https://mirrors.dotsrc.org/tinycorelinux/17.x/x86_64/tcz/pax.tcz.tree shows, pax depends on "many" other tczpax.tcz
coreutils.tcz
gmp.tcz
squashfs-tools.tcz
liblzma.tcz
lzo.tcz
libzstd.tcz
liblz4.tczThe package-manager belongs in the base, the base must / should be small, but pax+deps is not small size for now by "TC developers standards". Maybe I am wrong, but I know how hard / long was the discussion on TC boot / config parameters: a 4 byte file (containing just a boot option as text) have 4KB (a page) in RAM etc.
I wish you success, because I want TC to evolve. From my point of view the "libs dependency hell" was solved by an AWK engine or can be a C-compiled software (like in Arch-linux or Alpine-linux ). Maybe your focus is in download speed, or parallel sources; where is the bulk CPU consumption, in server or client, etc. I mean do you want to "protect" the web-server energy/bandwide by transferring the energy bill to the client-user, etc. I just ask...
I completely agree with everything you said. I'll tackle them one at a time...
1. Yes the project is a shell script to make is portable to all CPU architectures without having to compile anything. It's not as efficient as a compiled binary, but there is no gain this way since the tce-* package manager is also scripts.
2. The various output options are so that pax can be integrated into various software and not just for command line usage. Currently there is the default text, and two XML options that can be used with any web-based GUI. There is also a fifo option so that pax can run in a "client control mode". This will allow pax to basically work in a network where an administrator can perform software admin tasks on the clients without having to visit them (e.g. remotely installing, uninstalling, updating, etc). I still have to build the server-side, but one can be put in place by a savvy admin. I plan on expanding to include two more options: html and json.
3. The graphical interface for pax will be a web-based interface. I just have to port several other applications into TC before I can get that going. However, if any other developers on here are interested in building a different type of interface (e.g. GTK, QT, FLTK, etc), I will be at their disposal to assist.
4. The coreutils dependency is required because pax needs the 'stat' binary to perform some tasks. Unfortunately the busybox applet is not part of the TC ramdisk, so it requires that dependency. If pax were the default package manager in TC, it could just install a single file out of the coreutils package and leave the rest, but the default tce-* scripts don't have this ability, so I'm stuck installing the entire package. The squashfs-tools dependency I'm actually going to remove in the next version of pax. It's only used when building from source code or packaging pre-compiled software, of which the vast majority of users do not do.
5. Yes, everything should be as small as possible. If the TC team wants to add in the 'stat' busybox applet, that can reduce one of the two dependencies. I can remove the other one in a future version.
If I may: It will be nice to define first what you improve (in Tinycore!), to measure what we have already (for a common user) and then you state by how much you WANT (not necessarily to achieve for now) to improve (in KB size, KB/second, or % or whatever).
This is a great point. So there are several items:
1. Efficiency. Unless the code has been updated, the tce-* scripts install each package (and their dependencies), then call ldconfig, udevadm, and then the package installation script. While this is not a big deal when installing a package at a time in a running system, it's inefficient during the boot process when everything is getting loaded. pax doesn't do this. It installs all the requested package (and dependency) files, then executes those calls only once.
There is also an install option to load packages in a single or dual-stage process when booting the system. This can allow the device to boot faster while loading supplemental software in the background. This is also not possible with the tce-* package manager.
2. Uniform execution. I'm not sure about the tce-* scripts, but the syntax with pax is uniform across commands. For example, to copy, extract, or install packages from a different source (to an optional target directory) all has the same syntax with different actions:
pax -S /path/to/packages -{cei} PACKAGE(S) [TARGET DIRECTORY]
3. Single file. With pax there is one script to call, not many to perform different tasks. This has an advantage and a disadvantage. The advantage is that there's one program to learn, not multiple. It also enables synergy among it's switches (as defined above). The disadvantage is that the entire script must be loaded to perform a task, vs smaller individual script that do specific things.
4. Versatility. For example, pax can take a space separated list, list in a text file, or a directory as the parameter to use when performing an action:
pax -c package1 package2 package3
pax -c textfile.txt
pax -c /path/to/packages
This is not possible with the tce-* scripts.
5. Features. The feature set in pax is larger than that of the tce-* equivalents. There are only one or two features not yet implemented (one of which is searching) because I needed to see how TC performed this task beforehand so that it could be designed properly. It takes a long time to code, test/debug, and document all of this (4 months for the latest version of pax).
I think I've addressed the improvements in this reply - reduction of dependencies (which will require the TC team for coreutils) and the addition of a few outstanding features.
If you have anything else nick65go, feel free to reply. I enjoy the conversation!
Welcome
FAQ
Downloads
Wiki
Recent Posts