Riku,
> Here are some Real world numbers using real applications; pulled from
Maemo
> Repositories
> ICU 4.2> 8 Megs
> cLucene is> 3 Meg (Depends on ICU)
> Sword> 2 Megs. (Depends on cLucene)
> WebKit> 3 Megs. (Depends on ICU 4.2)
> Lets say I just put TWO bible apps (Both use Sword) on the device;
> Lets say Rapier: which is 35K And Katana: which is 94k
>>Which is pretty much the pathological corner case, not the average real
world scenario.
You might be correct -- they might be a corner case; but it IS from
REAL data that _I_ could easily supply since _I_ packaged them and _I_ was
very familure with the projects that use them. Quim made a comment, I
responded with REAL information that came from stuff _I_ did on Maemo.
http://maemo.org/packages/package_instance/view/fremantle_extras-testing_fre
e_armel/clucene-core/0.9.21b-0maemo1/
>>We need to engineer around average use cases, rather than focusing on
>>corner cases. Highlighting extremities makes great theater like this
>>thread shows, but doesn't bring us towards solutions.
However, it is a VALID USE case, what about Python, Ruby, or PHP, Java or
any number of any number of other scripting languages, or even things like
Boost or even liqbase. LOL, I can think of a dozen items off the top of
my head that are large, so it isn't a isolated case. My point was we need
to be careful about "requiring" inclusive packages. It wasn't about
ICU/Webkit, I just was trying to bring in some real numbers that I had some
idea about since _I_ packaged them up for Maemo.
>>Another thing people here seem to ignore: For developers *not* coming
from linux distribution/packaging background, importing a shared library
to their application project is infinitely simpler task than packaging
the same library (correctly!) and distributing it to a extras-style
repository.<<
Well, I can't totally comment on that -- I haven't done a RPM yet. But I
learned how to do a DEB in a couple hours of work. So, if RPM's are as
simple, then I think this is a invalid argument.
Nathan
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
