---- Eero Tamminen <eero.tamminen@xxxxxxxxx> wrote: >Err? >UBIFS used for rootfs is most certainly using compression. Wow... totally missed that. I haven't hacked around with it to that level, and missed it in the df listing some how. :P Yes, that does present challenges, but nothing that can't be overcome with some clever scripting. >Sorry, you lost me. >Where you're expecting this proposed package space estimationto happen and when? I would prefer to see it pre-install, with the info being sent to the App Manager using the same mechanism that's providing the details it gets now. It's getting package names, sizes, descriptions and the like from somewhere already. Tacking on more info should be pretty trivial, even if it's a pre-tack into the description text by a build script. It could (as I noted) be collected during install and show up in the package removal screen. It wouldn't be an up-front warning, but at least it would be something. It would also be more accurate, since it's post fact and monitoring _actual_ usage on the device. It would take into account things like compression, install script actions, link routing, dependent packages, etc. >> 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. :-) So you're advocating the user have no idea how large a package is? Not giving any details or hints as to how large it would be? What would you propose? "Big", "Medium", and "Tiny"? >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. That's the issue right now! The user doesn't have a distinction between rootfs and home. Then they get a message when trying to update that they "need more memory" on their rootfs. So they go into application manager, look for large packages, delete them, and still get told they need more space. That's because app manager right now only shows total package space, which is useless for this task. If the UI for uninstall showed how much each package (rough estimate) took in rootfs, the average user could make much better choices about what to uninstall to do updates. Again, this is to help less technical users. If they're expected to clear space on the rootfs to do updates, there should be a tool to show how much each package takes on the rootfs. The app manager is the clear choice to do this, since it can collect such data easily and is the tool most users will go to in order to delete apps to free up space. >That hypothetical 3rd party application could show also those and nothings preventing it from implementing package removal too. Yes, that's great. So let's re-implement the entire code base from app manager to find/list/catalog installed packages. Then hook into the actual app manager to figure out when it's installing things so we can do a pre/post snapshot during installs. Store that data in a separate place, and present it in a separate UI. Push this app through devel, then testing, then _maybe_ get it to Extras. And finally, start a mass campaign to educate people that this new tool exists, and that they need to install it (with App Manager) so they can then use to find this small piece of information they need for when updates come out and they are told they need more rootfs. Or, we could just add few lines of code to app manager to do a df pre/post, store the extra 4 bytes on rootfs usage in it's database, and show that data in 5 to 10 characters on the existing package removal UI, which everyone has installed and already knows how to use. And it will update automatically on 95% of the devices when released, either separately or as part of a PR update. Which do you think would be easier and more effective to do? To me, app manager is the clear choice. > That would include also their dependencies, but those could be shared between later installed packages. No solution will be 100% perfect. Nobody is asking for a 100% perfect solution that will take all things into account. All that is being asked is a simple _estimate_ of rootfs usage per package. Knowing that ioQuake and Angry Birds are both 68M is useless data for freeing rootfs space. Knowing that ioQuake takes 35M in rootfs, where Angry Birds only takes 1M on rootfs is much more useful, even if those numbers are 30% off actual space usage. Do you see the point I'm making? >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? With the exception of lage non-optified packages (like python or qt devel packages) most CLI packages are super tiny. Realistically, if implemented in app manager as discussed above, the first package that installs a large non-optified CLI package will still show that it used a ton of rootfs space. At least there's a reg flag being thrown, where now there's absolutely no indication of it happening. If people are installing CLI packages on their own with apt-get, then they know how to type df before and after to see space usage on their own. That's not the typical user, who is using app manager for most or all of their installs. _______________________________________________ maemo-users mailing list maemo-users@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
