The optification continues apace, but i wonder if it might not be a good idea anyway to make app manager more intelligent. What about building in a safeguard so that it will examine the package in question and grey it out/disable install if the package would fill root (or maybe any partion for more general usefullness).

It seems that deb tools should be able to ascertain how much space will be taken on each partition. If automating it is not practical, new fields, e.g.:

X-space-in-root

X-space-in-opt

might do the job, although more disruptively.

After reading about the state that filling root puts the N900 into, preventing normal users from filling the partitions seems like a good idea...

http://maemo.org/community/brainstor...ill_partition/

It's a bit harder than that as the root partition is a compressed filesystem, so the size reported by the debian packaging tools may not correspond to the size it actually uses.

It's a good idea though, and certainly worth some thought. At the very least it could issue a warning when it looks like it may run out of space.

I'm not sure I want my package manager to tell me what to do.

From my perspective, I'd rather Extras have a strict "optified or GTFO" policy, and users told they're on their own if they use extras-devel or extras-testing.

Another consideration is that the package itself has no idea how many filesystems will it's contents be spread over. Some of it might go to root, some to opt, some to Mydocs, some even to the external MMC, etc.

Thanks, i did not realize the root partition was compressed.

After working with the debian packaging system (and surely it knows which directories the files go to), it seems like it should be straightforward to calculate which filesystem each file in a package goes on.

Even using a repository where everything is optified, it's still possible to fill a partition. For example, /opt itself isn't any too large if a user goes crazy installing big packages.

Even in the present app manager there is a blue pill and red pill mode. Why not make the blue pill mode more bulletproof?

What I'm saying is that the packager has no idea how these partitions look like on the user side, only the presumption that nothing has been changed compared to the factory layout. In time, people might reformat, repartition, change filesystems, rebase/clone their roots, etc, all of which can influence the actual location (and amount) of actual package content.

I hadn't considered the case where the user has repartitioned. This is clearly an advanced user situation and not the usual case. Would it not be appropriate still to ship with App Manager set up to assume the default filesystem, and let those who chose to repartition also disable the protection? We're really trying to protect the average user here, not the hackers.