On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp <leio@gentoo.org> 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 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.

tar-1.20 has lzma support, so maybe it could handle this too, once it
goes into stable
--
gentoo-dev@lists.gentoo.org mailing list

>>>>> 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 it would also be possible to compile "lzmadec" without any need
for C++. Just call "make" in subdirs liblzmadec and lzmadec.

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 <leio@gentoo.org> 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 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.

tar-1.20 has lzma support, so maybe it could handle this too, once it
goes into stable.
--
gentoo-dev@lists.gentoo.org mailing list

>>>>> 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

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 sneaks in during development that depends on the C++
> standard library easily instead of finding things break later.

It's a pain in the ass for Release Engineering, too. At this point,
we're looking into how we need to modify the bootstrap sequence to
accommodate people using lzma for system (and lower) packages.

http://bugs.gentoo.org/show_bug.cgi?id=220074

We're already getting reports of this due to someone deciding that it'd
be a good idea to use lzma for our daily portage snapshots without any
discussion here. Luckily, we still have the other tarballs to use, too.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer

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 == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list

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 own repackaging of upstream
if they don't have a supported option. I think the only other option
would be to create an "lzmalite" package or something like that which
simply contains the decompressor in ordinary C. You could really turn
that into a separate package like gentoolkit or whatever - I wouldn't
actually embed the code into portage since that isn't the unix way and
it just forced other package managers (and other distros) to do the same
thing. An lzmalite package could have a life of its own and as a result
benefit from fewer bugs/etc.


But, I'm not going to be the one writing the thing, so feel free to not
listen to any of this...

--
gentoo-dev@lists.gentoo.org mailing list

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 this might mean doing our own repackaging of
upstream if they don't have a supported option. I think the only
other option would be to create an "lzmalite" package or something
like that which simply contains the decompressor in ordinary C. You
could really turn that into a separate package like gentoolkit or
whatever - I wouldn't actually embed the code into portage since that
isn't the unix way and it just forced other package managers (and
other distros) to do the same thing. An lzmalite package could have a
life of its own and as a result benefit from fewer bugs/etc.


But, I'm not going to be the one writing the thing, so feel free to
not listen to any of this...
All upstreams in question still use gzip, they have only dropped bzip2
support in favor of lzma.

--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 07 May 2008 16:23:12 +0300
Mart Raudsepp <leio@gentoo.org> 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) 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.

The new lzma-utils codebase uses liblzma, written in C. It's at the
alpha stage but supposedly supports encoding/decoding the current lzma
format "well enough" (;P). It probably has some fun bugs to find
and squish.

http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.col lin%40tukaani.org&forum_name=lzmautils-announce

--
fonts, gcc-porting, by design, by neglect
mips, treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Ulrich Mueller <ulm@gentoo.org> posted
18465.49899.138685.587639@a1i15.kph.uni-mainz.de, excerpted below, on
Wed, 07 May 2008 16:55:39 +0200:

> The decoder of lzma-utils is also written in C only.
>
> So it would also be possible to compile "lzmadec" without any need for
> C++. Just call "make" in subdirs liblzmadec and lzmadec.

What about USE=decode-only or something similar for lzma-utils, then? If
desired, it could even be masked on "normal" profiles, but would then be
there for the embedded and releng folks.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list