Gnumeric seems to be way too large

[mcewanw]

Now that Curaga has produced an extension for Abiword, I thought of enhancing my desktop with Gnumeric, but with only a slow dialup connection I am reluctant to download the 13 Mbytes app.

I rather suspect that Gnumeric shares some of the same libs as Abiword and that some of these libs have been included inside the gnumeric.tce (but I don't have a copy of it to check that). If so, could we now have a slimmed down/stripped Gnumeric extension created? [note that the Puppy Linux Gnumeric download (in their Puppy 4.x repository) is only around 3 Mbytes so clearly they have packaged most of their gnumeric dependent libs separately]

[curaga]

The file list is available at:
ftp://ftp.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tce/gnumeric.tce.list

There is indeed a lot of duplication, both with extensions and (!) the base...

[jpeters]

The file list is available at:
ftp://ftp.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tce/gnumeric.tce.list

There is indeed a lot of duplication, both with extensions and (!) the base...

As I recall, what libs to include with gnumeric was arrived at by consensus. If you know you'll be loading gnumeric,  you can remove all the duplicate (!) files  Curage has included for  abiword.   (which I don't need )    . 

[clivesay]

Seems that it starts to get very cumbersome to break out any libs that are shared amongst many applications. It definitely would be cool to truly have only one occurance of a lib in the repo and have it tagged to every app as a dep but that would require some incredible maintenance I would think.

So, I'm with ya on not wanting to download dupes when you are on a slow connection. I'm just not sure how you manage something like that within the repo without an unreasonable amount of work.

This is a good discussion to have as we are always working to strike just the right balance.

Chris

[Jason W]

I of course like each lib to be it's own extension so there is not library conflict that can result in broken apps, and since we have removed the version number from library extensions it is easier to maintain.  An upgrade to a lib extension does not require the .dep files of other apps to have to change along with it. 

The extension area is very modular and there are very few conflicting extensions.  Almost without exception everyone is on the same page about all of this and is doing a good job keeping it that way.

What this does make me think of though is that it is possible to make a self contained app directory under /usr/local if one wants to include dependent libs in their extension.  If a packager wants to include a certain version of a lib, and wants that app to run with that lib version regardless of updates to libs in the repo, all one would have to do is install their app under /usr/local/appname and use a LD_LIBRARY_PATH wrapper to set the library path for that directory so those libs are used in preference to the libs in base or other extensions.  That way the app would still be PPI compatible but self contained.   And this approach would keep that extension from creating library conflicts with other extensions.  This would give greater freedom to include whatever you want in your extension without affecting or conflicting with other extensions.

[roberts]

Isn't that called a .pbi by the PC-BSD folks? I believe they offer howtos on building such.
There is an advantage being totally self contained, but at the expense of much larger size per applicaton.

[Jason W]

Yeah, simply the same app directory concept as the .uci.  Unless a self contained extension was a tcz, the extra RAM taken up by duplication would outweigh any benefit.   Making each lib their own extension rather than making a self contained app allows others to use the libs for their extensions too, saving duplicating work as well as RAM space.  Upon further thought I don't want to encourage making extensions self contained except for special cases since our current way of doing things fits our goals very well.

[jpeters]

I'll resubmit without libc and libm, since the base versions now seem to work and saves a few megs.

I guess it's always possible to submit libs in a separate support extension. edit: I would think there might be times where apps require specific versions of libs.  (eg, Xorg libs & deps).

[mcewanw]

Thanks for the cut-down version; much appreciated, I downloaded the extension and use it often.

Spreadsheets are such a great tool - I prefer using Gnumeric to a calculator any day and often help my secondary school-aged daughter with her homework - using Gnumeric to build up solutions. She never realised how easy and useful spreadsheets were as a "blank sheet of electronic paper" on which you can lay out calculations, even though she has been "shown them" in operation as part of general computer studies work.

[jpeters]

I use gnumeric as a data-base, in addition to spreadsheets for all kinds of investment analysis (maybe I should have skipped that particular application.. ).  I wrote my own text calculator (in tcltk)  that  probably does what you can do on a spreadsheet....write out and solve equations.   I think spreadsheets were the first killer application for pcs....no end to what you can do with them.

note: I think expat needs to be in the dep file.

[Jason W]

expat2 has been added to the .dep files.

[junan]

i'm waiting for gnumeric that PPI Compatible.
It won't works using kernel parameter local=hdXY 

please recompile it..

[jpeters]

i'm waiting for gnumeric that PPI Compatible.
It won't works using kernel parameter local=hdXY 

I can copy gnumeric  anywhere, and it still works.  Gnumeric relies on dependencies, so you many have some configuration issue on your particular setup. Make sure expat2 is loaded (I think Jason recently added it to the dep file).

 

[junan]

ok ... i will try to move to /usr/local ... hope it will work.

[jpeters]

ok ... i will try to move to /usr/local ... hope it will work.

Check the file list to make sure you have everything. PPI shouldn't change anything and you can place the exec file anywhere.