> > > > I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages > > > > perfectly... are we talking about 4 Mb mechines? > > > Do you realize how much ram dpkg itself already takes up? Add that to > > > bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, > > > doing this, and you need 16megs *free* physical memory just to keep from > > > swapping. As for 4 meg machines, the current gzip setup is almost > > > unbearable just for that (believe me, I have an 8 meg system, and I don't > > > want to even imagine a 4 meg system trying to handle dpkg, much less > > > dpkg+bzip2). > > > > Uhm.. you are right. But it could still be used for Packages.gz and for the > > source package. Many packages are now being packaged in bz2 upstream (eg. > > lftp, one of mine)... > > For Sources and Packages that's fine, IMO, but your assertion about > source packages is a little misleading. apt-get source for gcc and > glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. > This is done with little loss of space over straight .bz2. A new format > and hacking is not needed for you to use this already (packages doing this > need to Build-Depend on bzip2).
That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. > [1]: Also check openldap, shadow and pam for the same style setups. Yes, > it's sort of a hack, but it's a clean hack and the system provides much > more than a way to package up .bz2 tarballs. I'll avoid that hack as much as I can... =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
