On Fri, Jul 15, 2005 at 01:15:00AM +0200, J.A. Bezemer wrote: > >On Thu, 14 Jul 2005, Steve McIntyre wrote: >> >> Yes, exactly. We can do quick-and-dirty size estimation as we copy >> files in, but the only way to know _exactly_ how big the image will be >> is to use mkisofs. Hence the "within a small margin" above. I'm hoping >> we can guesstimate sizes reasonably well up to ~95% of the target >> size, and go for the slower option from there: >> >> * Dump stanzas into the Packages/Source file and compress them >> * Update Release file >> * Fill in any last files >> * Run mkisofs --print-size >> >> The plan will then be to fill the discs as much as possible. In fact, >> the best way might even be to go 1 package/source file too far, then >> roll back. > >...and if that package happens to be big, like game data or somesuch, skip >that package and try adding the next one (incl. deps). Iterate until you are >within, say, 100kB of the disc size. Requires a "staging area" that includes >all a package's deps, which is either committed or dropped as a whole. Yes, exactly. And for a multi-arch / binary+source CD we'd have to consider all the files for each package in the same way. >By the way, "guesstimating sizes" is quite doable in three steps: >1. Begin with all non-package content like installer, docs >2. Take mkisofs --print-size and add "something" for Packages/md5sums >3. For each package to add, round size up to 2048-multiple That's _almost_ what I was thinking, yes. But at least to start with we don't need to run mkisofs --print-size at all, and it will be expensive. We can calculate reasonable guesses simply by adding up the numbers ourselves, and fall back to mkisofs near the end. -- Steve McIntyre, Cambridge, UK. steve@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Attachment:
signature.asc
Description: Digital signature