1

I'm in the middle of doing an upgrade on a really slow machine. It's an Intel Atom that's a few years old. It's perfect for watching video and using XBMC but it really honks at decompressing hundreds of updates (like you do in a release upgrade). I've got another upgrade to do on this once this one completes.

I mused to the General Chat room today that it would be cool if I could proxy those package downloads through a faster local server that could proxy the requests, decompress the packages and pass them on.

So still in planning, I have a few questions:

  1. Is is possible to have a deb package that isn't compressed?
  2. How can I remove the compression from a deb?
  3. Will removing the compression knacker the checksums and if so, how do I fix that?
Oli
  • 289,791
  • 117
  • 680
  • 835

2 Answers2

1

1) Not really, no. You can theoretically use the lowest level compression at build-time of the debs, but the Ubuntu builders don't do this. The slow part is probably not the decompression, but the unpacking of files and writing them to disk. Several things can affect disk I/O times here, including BIOS settings, drive rotational speed, and drive type. You could theoretically have the data archive inside the deb be data.tar though it would still have slight compression (or inflation), and wouldn't help with the speed of writing to disk.

2) See 1).

3) Yes, it would, if you were to take a binary deb and replace the data.tar.gz inside it, the size, timestamp, etc… would change. To be able to do something, you'd need to do it at build time of the deb package.

On the other hand, as I said, the speed issue is probably writing to disk. You can check your BIOS to change some settings for the disk. If your using a SATA disk, and your BIOS is set to communicate with it as IDE/ATAPI, then read/write speed is going to be extremely slow. Change the setting to AHCI if avaialble. Another common issue is disk RPM if you're not using an SSD. You didn't specify what size or RPM disk you are using, but a 2.5" 4500-5400 RPM disk is going to be slower than a 3.5" disk that does anywhere between 7200-15000 RPM. And a SATA I (1.5Gbps) disk is going to be slower than a SATA II (3.0 Gbps) or III (6.0 Gbps) disk. Disk cache size also plays an important role here. You also didn't say which Atom you had, or how much RAM, but they aren't as slow as one might think. They aren't a top shelf i7, but the amount of compression used in deb packages is not generally a problem for them.

dobey
  • 40,344
  • 5
  • 56
  • 98
  • It's a nettop so it's 2.5", sub-5000 RPM, slow slow slowness and no space to stick a 3.5". I keep meaning to buy it an SSD but it's hard to justify when most of it runs from RAM. If only they made tiny (<10GB) cheap SSDs. – Oli Nov 01 '13 at 14:27
  • I've added an answer for point 1. It might not be possible while generating a package but it can be done retroactively which is what I was imagining in a server-in-the-middle scenario. – Oli Nov 01 '13 at 14:41
  • You could get an SSD+HDD disk. I am using one in my workstation, and in my PS3. 750GB Seagate Momentus XT are what I have. Also, 20-60 GB SSDs can be had relatively inexpensive as well. – dobey Nov 02 '13 at 00:57
0

For stripping the compression here's what I've come up with (this by no means answers anything else):

ar vx debianutils_4.3.4_amd64.deb
gunzip data.tar.gz
ar d debianutils_4.3.4_amd64.deb data.tar.gz
ar q debianutils_4.3.4_amd64.deb data.tar

The package is bigger. The checksums are completely off... But it's still a valid package, sans compression.

Oli
  • 289,791
  • 117
  • 680
  • 835