* Mart Raudsepp <[EMAIL PROTECTED]> schrieb:
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 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 be
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 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 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
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
> >
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 ha
On K, 2008-05-07 at 15:34 +0200, Fabian Groffen wrote:
> 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 b
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)
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 th
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
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
--
--
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 s
> 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, 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 on
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
> kilobyte
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 un
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
19 matches
Mail list logo
