Thread: Tizen?
View Single Post
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#175
Originally Posted by attila77 View Post
Sorry, been there, done that (with Qt, Mobility and PyQt). It's a nightmare, it's just so easy to break/drive the upgrade mechanism into an error that it's not even funny.
I'm not familiar with that stack so can't comment. What makes it so fragile?

As for several copies, again, in a weird sense it's the lesser of two evils. When you have a thousand (yes, I'm exaggerating) apps using a shared lib, they will inevitably be using multiple, maybe mutually exclusive versions.
Which is fine, on a sane OS you can have multiple versions of any particular lib installed in parallel for whichever app depends on them. You'll still end up with just a handful of them rather than a thousand. More importantly that's maintainable - if a security issue is discovered in libfoo, you just update that and the user is safe again. The "modern mobile" user on the other hand will have to update each app separately, and will never know whether all libfoo bundlers bothered to issue updates, or how many and which ones remain exploitable. Never mind the storage, RAM etc cost (why on earth does a phone need 1GiB of RAM and compcache and flash-based swap again?)

When these apps and libs are open source, and have maintainers, all is well - you ping people, they repack, patch, etc. In a store, that doesn't happen - you mostly only have binaries, the users expect them to work even after upgrades, you must rely on the original author to fix whatever is broken, etc.
Even in a "store", why shouldn't I be allowed to package my own libs sanely for my own packages to use?

Anyway, this whole topic was discussed ad nauseum in meego-dev when/where it was more appropriate, we certainly won't solve it here. Besides, it doesn't matter much anymore, what with the wench being dead and all.

Apt-repositories (and for zimon, rpm correspondents are not much better are horribly unsuited for large package counts (take a look how much time and memory it takes to update/refresh on an N900 that has all extras* repos enabled).
Well, if you draw your conclusions based on that particular implementation... IME it was even perceptively slower than the Diablo version on Diablo hardware, and that was 18 months ago when fremantle extras was still young. Heck, even my lowly access point (a 125MHz MIPS with 16MiB of RAM) can process its package repository (1439 packages right now) faster than the N900 could its own.

A modern package format (and corresponding repositories) should be streamable, resumeable, filterable, downloadable and installable in parallel, support selective part-downloads, multi-arch, reconstructable, delta-upgradeable, have indexed and easily accessible metadata, etc, etc.
Apart from parallel installation (for which I don't see the point, having seen it on Android where it simply caused heavy I/O contention and actually slowed things down) which of the above aren't provided by say a yum/rpm repository?
 

The Following 5 Users Say Thank You to lma For This Useful Post: