Code review comment for lp://staging/~jmarsden/ubiquity/lp775124

Stéphane: I thought that was new when I saw it, but I didn't check the bzr history of it.

To me, that code looks like a workaround for another side-effect of the *2 problem. Basically *2 is not really the correct "fudge factor" for many Ubuntu flavours, IMO.

If we make the preseeded variable the total disk space to ask for, as you suggest, then every time the size of a default install changes, we might need to edit the seed file. If instead we make the preseeded variable the offset from the filesystem.size, that is, the minimum amount of free space needed in addition to the file size being installed, then the total size requirement will 'automatically' change as the size of the stuff in the default install changes, and the seed file only needs a manual update when the amount of free space needed by the installer changes.

My guess is that the size of the default install could change a lot more often than the amount of extra space needed by the installer to work in. On that basis, it seems more useful to me to preseed the offset, the "extra space" needed, rather than the total space requirement.

Based on Colin's suggestion, I have played with using debconf info from Python in test programs, and they work fine if the program is called as debconf ./mytestprogram.py -- but I don't yet know how to access the debconf database correctly/safely from inside a ubiquity plugin. Will the debconf database have already been opened somewhere when the plugin code is called, so there is an existing (global?) db object the plugin can use to do something like

  db.get('ubiquity/minfreediskspace')

with? Or do I need to do the

  import debconf
  db = debconf.Debconf()

inside ubi-prepare.py itself?

Is there documentation somewhere detailing the environment that ubiquity plugins such as ubi-prepare.py run in, and what things ubiquity has already done "above" them which they can make use of? Or do I just have to read all the code :)

Thanks,

Jonathan