Re: [gentoo-dev] RFC: lzma tarball usage
* 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 -- - 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
Re: [gentoo-dev] RFC: lzma tarball usage
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 message part.
Re: [gentoo-dev] RFC: lzma tarball usage
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 Ehmm... you're right. Sorry about that. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 prefix-only bug as the version in the tree never did Ehmm... you're right. Sorry about that. ive added a comment to the ebuild so as to future proof me or anyone else forgetting about this gotcha. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: lzma tarball usage
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) 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. I'd rewrite the C++ code in plain C if isn't that complex... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 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 addition to using lzma for no good reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 doesn't have a dep in addition to using lzma for no good reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. Note that we're also speaking about downstream lzma archives. Like in sys-apps/net-tools, where lzma hasn't been adopted even by upstream. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 addition to using lzma for no good reason) Chill, relax and cool down. Well, I said how it is. I don't see anything in it that indicates I am so upset and angry that I need to do these things. I did however loose hours of work time, but that's life. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. This is what I am doing with this as well, in addition to the bug reports. But as this is widespread to at least 4-6 system packages, I brought it up here as well to ensure this is not something I have to fight against in overlays and time wastes continuously in the future. Oh and net-tools has not distributed anything in .tar.lzma, so this has nothing to do with following upstream in any shape or form in this case. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: lzma tarball usage
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. 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. 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. 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. coreutils and linux-headers come to my mind out of system packages right now. I'm sure more dragons await me. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
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 smaller files (less bandwith) and decompresses faster. They no longer provide the bzip2 versions of archives for newer releases IIRC, so it's either tar.gz or tar.lzma. 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. See above why it might not just be 'cause you can. coreutils and linux-headers come to my mind out of system packages right now. I'm sure more dragons await me. m4, that one gave me some headaches, because lzma-utils required some eautoreconf, which introduced a nice cycle. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 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. 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. -nc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
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 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
Re: [gentoo-dev] RFC: lzma tarball usage
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
Re: [gentoo-dev] RFC: lzma tarball usage
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
Re: [gentoo-dev] RFC: lzma tarball usage
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 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
Re: [gentoo-dev] RFC: lzma tarball usage
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
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
Re: [gentoo-dev] RFC: lzma tarball usage
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
Re: [gentoo-dev] RFC: lzma tarball usage
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
