| 1 |
Hello, |
| 2 |
|
| 3 |
Over the course of this year, a lzma-utils buildtime dependency has been |
| 4 |
added to a few system packages, to handle .tar.lzma tarballs. |
| 5 |
This has huge implications on the requirement of the system toolchain, |
| 6 |
which is highly disturbing from a minimal (lets say embedded) systems |
| 7 |
concern - lzma-utils depends on the C++ compiler and the libstdc++ |
| 8 |
beast, while a minimal system would like to avoid this at all cost. |
| 9 |
|
| 10 |
I do realize one would remove build-time dependencies and the toolchain |
| 11 |
on an embedded system on deployment anyway, but this means gcc USE=nocxx |
| 12 |
USE flag is pretty much useless, while it would be nice to use it to |
| 13 |
ensure that nothing sneaks in during development that depends on the C++ |
| 14 |
standard library easily instead of finding things break later. |
| 15 |
|
| 16 |
This is a plea and also a request for comments on the matter of |
| 17 |
using .tar.lzma tarballs or not, and for what packages this is |
| 18 |
acceptable and for what not. |
| 19 |
|
| 20 |
I'd be happy if some other unpacker is used than lzma-utils - one that |
| 21 |
does not depend on libstdc++ - I'm sure it can be done, heck it's done |
| 22 |
in integrated form in some other projects in less than a couple |
| 23 |
kilobytes of code for the unpacking from a VFS. Meanwhile please |
| 24 |
consider using the upstream provided .tar.gz tarballs instead and not |
| 25 |
roll patchsets in .lzma just cause you can. |
| 26 |
|
| 27 |
coreutils and linux-headers come to my mind out of system packages right |
| 28 |
now. I'm sure more dragons await me. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
Mart Raudsepp |
| 33 |
Gentoo Developer |
| 34 |
Mail: leio@g.o |
| 35 |
Weblog: http://planet.gentoo.org/developers/leio |
Archives