Compressing packages with bzip2 instead gzip?

[Carlos Ribeiro]

On 12/9/05, Mikael Eriksson <mikael_miffe_eriksson at yahoo.se> wrote:
>
> On Thu, Dec 08, 2005 at 06:18:00PM -0800, Matt Zimmerman wrote:
> > On Wed, Dec 07, 2005 at 04:58:28PM +0200, Timo Jyrinki wrote:
> > > Speaking of language files, those also compress better with bz2 even
> though they
> > > are in mo format:
> > > -rw-r--r--  1 root root 1356095 2005-12-07 16:51 LC_MESSAGES-
> fi.tar.bz2
> > > -rw-r--r--  1 root root 1590691 2005-12-07 16:52 LC_MESSAGES-fi.tar.gz
> > >
> > > (compressed etch's /usr/share/locale/fi/LC_MESSAGES to get those)
> >
> > That's why the language pack .debs are already compressed with bzip2.
> >
> A repack of language-pack-gnome-* shows that most would be smallest when
> compressed with 7z. And the rest is smallest with gzip -9.
> See the attached file.
>

An idea: the compression tests could be done automatically by a 'repacking'
script on the central repository. It's a computationally intensive task, but
it could be done in the background. The script would do the following:

-- get the original .deb
-- repack the components with a number of different tools
-- select the smallest ones
-- generate a new deb file

Although slow, this is at least an automatic procedure -- something you can
throw at a server to work over 24x7 day after day, perhaps using otherwise
unused cycles. The savings in bandwidth (both server side and user side)
could potentially pay for it. And we would avoid putting one more strain on
the back of packagers (testing to check which tool compresses better) --
they could always work with .tar.gz for development.

(After writing I realized that the repacker script can also be distributed
to do this automatically... but for some reason I believe this is something
that can be handled by a server in the repository.)

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051209/e96be1d7/attachment.htm