[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the CD team: plans for debian-cd v3.0

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

Reply to: