* Mart Raudsepp [EMAIL PROTECTED] schrieb:
big_snip /
IMHO, lzma is far from being mature enough from being suited as
packaging format for production systems. And actually, I don't
see the benefit over well-approved tar+(gz|bz2).
So my vote is to NOT use it for gentoo source packages.
cu
On Wednesday 07 May 2008, Fabian Groffen wrote:
m4, that one gave me some headaches, because lzma-utils required some
eautoreconf, which introduced a nice cycle.
must have been a prefix-only bug as the version in the tree never did
-mike
signature.asc
Description: This is a digitally signed
On 10-05-2008 03:32:08 -0400, Mike Frysinger wrote:
On Wednesday 07 May 2008, Fabian Groffen wrote:
m4, that one gave me some headaches, because lzma-utils required some
eautoreconf, which introduced a nice cycle.
must have been a prefix-only bug as the version in the tree never did
On Saturday 10 May 2008, Fabian Groffen wrote:
On 10-05-2008 03:32:08 -0400, Mike Frysinger wrote:
On Wednesday 07 May 2008, Fabian Groffen wrote:
m4, that one gave me some headaches, because lzma-utils required some
eautoreconf, which introduced a nice cycle.
must have been a
Mart Raudsepp wrote:
Hello,
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)
On 08-05-2008 21:45:00 +0300, Mart Raudsepp wrote:
d) too early adoption in critical system packages - once above issues
are solved, higher levels should be using it first, before critical
system packages (for example shows in the circular dep hell with m4)
been there, done that.
e) It has
On Thu, May 8, 2008 at 9:09 PM, Fabian Groffen [EMAIL PROTECTED] wrote:
e) It has been suggested the support should have been added with new
EAPI instead of local build deps (some of which are missing, for
instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format
net-tools
On N, 2008-05-08 at 21:09 +0200, Fabian Groffen wrote:
e) It has been suggested the support should have been added with new
EAPI instead of local build deps (some of which are missing, for
instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format
net-tools doesn't have a dep in
Hello,
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 -
On 07-05-2008 16:23:12 +0300, Mart Raudsepp wrote:
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.
Just as a little background:
GNU chose to switch from bzip2 to lzma, for it produces
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote:
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
On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp [EMAIL PROTECTED] wrote:
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
On Wed, 07 May 2008, Natanael Copa wrote:
busybox has unlzma and seems to be a part of system.
Should also be easy to create a really tiny unlzma from the busybox
source and ship with portage, or create a patch for tar or something.
The decoder of lzma-utils is also written in C only.
So
On Wed, 7 May 2008, Benedikt Morbach wrote:
tar-1.20 has lzma support, so maybe it could handle this too, once it
goes into stable
This doesn't help, since it needs the lzma binary as a filter.
Ulrich
--
gentoo-dev@lists.gentoo.org mailing list
Hi,
I sent this to -dev to, but I think as an ordinary user I can't write there...
On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp [EMAIL PROTECTED] wrote:
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
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote:
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
Hi,
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to
save a few bytes IMHO isn't worth it.
cu
--
Enrico Weigelt wrote:
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to
save a few bytes IMHO isn't worth it.
Keep in mind that this might mean doing our
Richard Freeman wrote:
Enrico Weigelt wrote:
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to save a
few bytes IMHO isn't worth it.
Keep in mind that
19 matches
Mail list logo
