Core system compressors and decompressors should not depend on more than C.
Eh???
Reopening, as this is a big problem for small systems to workaround. Upstream provides tar.gz tarballs, use em please.
Please heavily consider using the upstream provided tar.gz files instead of tar.lzma - lzma-utils is a very bad dependency to have on a system package. It involves having to have gcc/gmp with cxx supports and that means having to have cxx providing gcc in (a custom catalyst embedded) stage1 just for that at build time, and so on. The world isn't ready for lzma tarballs like this if the world doesn't develop a light-weight decompressor tool that this can built-time dep instead of on the lzma-utils beast.
(and of course then ship the patchset packed in another way as well...)
CCing wolf31o2 for his reference, as he had desires to get rid of this dependency as well
I'm all for using the gzip version especially considering the following e-mail I got from the lzma-utils announce list.. A new snapshot of the git tree is available: http://tukaani.org/lzma/lzma-4.999.3alpha.tar.gz The new LZMA Utils will use version numbering scheme similar to many other free software projects. The first stable version will be 5.0.0 (but I don't know when). The version number of LZMA Utils will have nothing to do with the version number of LZMA SDK anymore. Development has stagnated during the past few months due to bunch of security problems found from the file format design and some other file format issues. These issues aren't fixed in this snapshot. To get the problems fixed and also the project out of alpha stage in this life, it is likely that the file format will change quite a bit and become significantly simpler. It should simplify the actual implementation too. Using liblzma to encode and decode LZMA_Alone format files (the current/old .lzma format) should be quite OK now. The code is very probably not as stable as LZMA SDK is, but some people find liblzma working "well enough" when operation is restricted to LZMA_Alone files. Keep in mind that I don't track API/ABI changes yet, so upgrading between versions may break things.
So, in trying to understand this problem, do any of the package managers have a problem with lzma? Is introducing a dependency on C++ in a system package undesirable? I think these are issues that need more discussion before QA can make any sort of decision on this issue. (preferably on the mailing list, in the form of a generic question if depending on C++ in a system package is a bad thing)
nothing to be done here
There's not really any reason, release-wise, to not allow C++ in system. Of course, there's no C++ in GCC and such in stages 1 and 2, so it can potentially cause issues when release building due to possibly being before GCC/glibc/etc. get recompiled. There's not really a clean solution until USE deps can be used. So long as we're aware of the issue and can work around it, I see no reason to create such a restriction for the tree. Just my 2 cents from the release side.
(In reply to comment #7) > So, in trying to understand this problem, do any of the package managers have a > problem with lzma? Is introducing a dependency on C++ in a system package > undesirable? The problem is that this means a c++ compiler and libstdc++ and so on is necessary to have, which is all fine and good when you are thinking about a desktop or a server, but a seriously big issue when you think about embedded systems. Heck, libstdc++ itself could almost be bigger than the whole storage available. At least it can be purged later, but something you need might have used libstdc++ without you knowing, because you needed it for unpacking a tarball... Anyhow, lzma-utils had a nocxx USE flag added a while ago with some changes to src_unpack too I believe, that allows to unpack lzma tarballs by portage without the C++ parts of lzma-utils around, so this bug is really FIXED, not just WORKSFORME. Just wanting to sound the embedded horn for qa@ a bit ;)
