Hi,
ext Craig Woodward wrote:
---- Eero Tamminen <eero.tamminen@xxxxxxxxx> wrote:
Compression can make normal ASCII data into 1/3 of its size
Yes, wonderful. Is a default N900 using a compressed filesystem?
NO. Why are we talking about it? Moot point.
Err?
UBIFS used for rootfs is most certainly using compression.
For example the 20MB icon cache file (which is generated so it's
not in any package) that was earlier the largest issue for SSUs
(due to Gtk keeping old versions open) and which we removed for
PR1.1, took "only" 3MB of the rootfs space per instance.
Btw. In case you're interested, here are the technical details
which explain why even the file system itself cannot give very good
estimate on how much "free space" it has:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_spaceacc
And the issue with that is that package doesn't know into which Fremantle release it's going to be installed.
Doesn't the package manager send some kind of identifying info?
Sorry, you lost me.
Where you're expecting this proposed package space estimation
to happen and when? When creating a package? Before installing it?
After it's installed?
If it's before install, what would provide that information to device?
[...]
it's not saying it will take 17,367,483 bytes; it says "17.4M".
Which I think is too accurate number when the things I mentioned
are taken into account. :-)
[..]
I think it's a bit too confusing to have on the Application Manager UI.
I disagree. It think it's absolutely needed in the package manager,
especially when the app manager is telling users "insufficient
rootfs space" when trying to do PR updates.
/home is larger, but it can also run out of space.
Root running out of space is more important though because if it becomes
full (so that even root cannot write anything there), the system may not
anymore boot up. /home partition becoming full means that applications
may not behave correctly (tracker cannot index new files, so media
player doesn't show them, email cannot be fetched etc).
The app manager is the default tool they're going to use to install
and remove packages. Knowing how much space a package takes up on
the rootfs is critical in selecting which packages to remove to make
space for such an update. Removing a non-optified 8M package is
going to free a lot more space on the rootfs than removing an optified
one that shows 60M of usage. But you have to be able to tell if it's
optified or not, which right now there's no way of telling.
>
Maybe there could be a separate 3rd party application
That would be great too, but having it in the app manager would make
it that much easier. It's one small piece of metadata, a few bytes
per package.
Well, you're free to suggest such an UI change, but I have my doubts
about how well less-technical users understand the distinction between
rootfs and /home etc. I assume you're suggesting that these values
would be shown in the UI always?
Even if it's collected during install (doing a df
pre/post and storing that per block device), it's something.
That would include also their dependencies, but those could be
shared between later installed packages.
Nothing but the app manager can do that though, since it's the one
doing the installs. And really, nobody wants to hop from one app
to the other to find/delete rootfs hogs.
And what about the non-UI packages that aren't shown in the Application
manager UI (for a good reason) and which also take space?
That hypothetical 3rd party application could show also those and
nothings preventing it from implementing package removal too.
- Eero
_______________________________________________
maemo-users mailing list
maemo-users@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users
