Bug 436718

Summary: Change Source0 to use tar.gz rather tar.lzma
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: jnovy, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-10 05:35:15 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Robert Scheck 2008-03-09 17:47:40 EDT
Description of problem:
Please change Source0 to use tar.gz rather tar.lzma -- lzma is only introducing
overhead and rpm.org has no lzma support in rpm, this is not rpm5.org ;-)

Anyway, I can't see any half-good reason to use lzma in favour over gz as long
as there is no support in RPM for it, so please switch back to gz again.

Version-Release number of selected component (if applicable):

Expected results:
Please apply the following patch or better:

--- coreutils.spec       2008-03-06 13:21:32.000000000 +0100
+++ coreutils.spec.rsc   2008-03-09 22:44:47.000000000 +0100
@@ -6,7 +6,7 @@
 Group:   System Environment/Base
 Url:     http://www.gnu.org/software/coreutils/
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.lzma
+Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.gz
 Source101:  coreutils-DIR_COLORS
 Source102:  coreutils-DIR_COLORS.xterm
 Source103:  coreutils-DIR_COLORS.256color
@@ -54,9 +54,7 @@
 BuildRequires: libacl-devel
 BuildRequires: gettext bison
 BuildRequires: texinfo >= 4.3
-BuildRequires: lzma
 BuildRequires: autoconf >= 2.58
-#dist-lzma required
 BuildRequires: automake >= 1.10.1
 %{?!nopam:BuildRequires: pam-devel}

@@ -89,11 +87,7 @@
 the old GNU fileutils, sh-utils, and textutils packages.

-#do not unpack in setup because of lzma is not yet supported in setup macro
-%setup -q -c -T
-cd ..
-lzma -dc %SOURCE0 | tar xf -
-cd %name-%version
+%setup -q

 # From upstream
 %patch1 -p1 -b .verbose
Comment 1 Jindrich Novy 2008-03-10 05:33:16 EDT
LZMA is a mature compression tool that introduces both significant compression
and decompression improvement in comparison with classical gz and bzip2
compressor. The argument that RPM doesn't have lzma support is bogus since one
can decompress the installation tarball himself with minimal effort and no risk
of regressions/brokeness.

Also consider that LZMA is also an official upstream format for coreutils
releases. This is NOTABUG IMO.
Comment 2 Ondrej Vasik 2008-03-10 05:35:15 EDT
Sorry, but upstream migrated from bzip2 to lzma and I will use lzma ... tar.gz
of coreutils-6.10 is 8.8M , lzma is 3.6M - and I don't see any reason why to use
tar.gz instead of lzma. Following spec file construction is working correctly and
without troubles and there is already requested (afaik) to support lzma in rpm
setup macro. Then I will change spec file back - to the simple %setup -q . lzma
archives are now used by more packages ( e.g. texlive ) so I really don't see
any reason to go back to tar.gz tarballs.
Lzma is not introducing overhead, lzma is reducing traffic - 5M smaller than
tar.gz and 1M smaller than tar.bz2 in the case of coreutils. Therefore I see the
usage of it reasonable (in addition with no support of tar.bz2 by upstream in
latest version of tarball).
So closing NOTABUG - feel free to add ANY GOOD REASON to go back to tar.gz .
Size of lzma rpm is only 206666 - so even if you have to download it, it causes
less traffic than usage of 5M bigger tar.gz tarball .
Comment 3 Jindrich Novy 2008-03-10 05:42:29 EDT
btw. lzma support is already committed in rpm- head, see bug #433188.