Over the course of this year, a lzma-utils buildtime dependency has been
added to a few system packages, to handle .tar.lzma tarballs.
This has huge implications on the requirement of the system toolchain,
which is highly disturbing from a minimal (lets say embedded) systems
concern - lzma-utils depends on the C++ compiler and the libstdc++
beast, while a minimal system would like to avoid this at all cost.
I do realize one would remove build-time dependencies and the toolchain
on an embedded system on deployment anyway, but this means gcc USE=nocxx
USE flag is pretty much useless, while it would be nice to use it to
ensure that nothing sneaks in during development that depends on the C++
standard library easily instead of finding things break later.
This is a plea and also a request for comments on the matter of
using .tar.lzma tarballs or not, and for what packages this is
acceptable and for what not.
I'd be happy if some other unpacker is used than lzma-utils - one that
does not depend on libstdc++ - I'm sure it can be done, heck it's done
in integrated form in some other projects in less than a couple
kilobytes of code for the unpacking from a VFS. Meanwhile please
consider using the upstream provided .tar.gz tarballs instead and not
roll patchsets in .lzma just cause you can.
coreutils and linux-headers come to my mind out of system packages right
now. I'm sure more dragons await me.