[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandrake-cooker
Subject:    Re: [Cooker] better compression of RPMs ?
From:       Liam Quin <liam () w3 ! org>
Date:       2005-06-30 17:41:54
Message-ID: 20050630174154.GB12857 () w3 ! org
[Download RAW message or body]

On Thu, 2005-06-30 at 10:58 +0200, Olivier LAHAYE wrote:
I think that there is 2 different problems here.
> 
> 1st SRPMS: they are curently compressed using bzip2. We all know that
> bzip2 is less efficient that 7zip (in terms of compressions ration,
> compression speed and decompression speed). Why not switch to 7zip for
> SRPMS?

As long as rpm could detect the format automatically and switch, the
only real problem I see is that Mandrake srpm files would no longer
work with alien, apt, on older Mandrake systems, on other systems,
with other people's tools.  But this is a big problem. A likely
reason to use a src rpm is so you can rebuild it for your own system.

If the binary format of the rpm is going to change, better to give
it a new name and fix any other problems at the same time.

> 2nd: RPMS: As a sysadmin, I don't care about uncompression time. All
> new CPUs since 3 years are far enough powerfull to have acceptable
> install time even if it increases by 40%.
I dispute that.

(1) maybe you don't install often on laptops -- they are usually
    much slower than desktops

(2) I've watched people who used Mandrake (as was) Linux -- e.g.
    an undergraduate studying English, who wanted to be able
    to write and print her essays and research them on the Web
    (and to use AIM and IRC).  For her, if the system went
    wrong, she reinstalled.  And if the installation Linux
    took too long or was too hard, she went back to Windows.
    GNU/Debian Linux [tm] lasted a few days I think.  Mandrake 9
    lasted the whole year, because the reinstall was quick and
    easy.

(3) Linux used to have a reputation for running on older hardware.
    let's not forget that not all users have new and powerful
    computers.

> More over, I think that slowness is in the 
> dependancies check or somewhere in the "preparing" install phase.
This part would need to be measured.  Let's not guess.

> IMHO, great speed gain could be obtained if , during installation of a
> group of package, the next group of package would be downloaded in //.
I think this is a good idea.  You'd have to special-case wget, curl,
rpm, md5tools etc, I expect, as now with urpmi --auto-select.

> Having hdlist files compressed with 7zip would be realy cool too as
> right now is takes time for urpmi.update -a
This would work well if the hdlist file was renamed, so that older
systems could still use their own urpmi.

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

[prev in list] [next in list] [prev in thread] [next in thread]