Off-Topic > Off-Topic - Tiny Tux's Corner
Applications and bundled libraries
roberts:
A very interesting article concerning the future direction of Linux applications.
http://lwn.net/Articles/378865/
I was always aware of OSX style of application and bundled libraries.
I believe Gobo Linux also uses this method.
It does mean using much more memory and disk space.
I had seriously considered this model for Tiny Core.
The advantage being easily unmounting self contained applications.
lucky13:
PC-BSD also uses self-contained applications.
http://www.pcbsd.org/content/view/39/30/
It doesn't necessarily need to use a lot more memory/storage. It depends how many libraries are deemed "essential" and therefore in a base (whether in a distro's base or in some package) -- e. g., so that the most commonly needed GTK-related libs are either in the base or in one grand unified package rather than in separate packages. That would mean that some users would end up with certain unnecessary libraries (rather than the piecemeal approach which saves a marginal amount of space) just to use some small application built off some of those combined libraries. I always thought it would make more sense to bundle more of those kinds of things anyway, and IIRC that was one of the suggestions I made if DSL had gone to more of a rox-ish AppDir paradigm to get around the inode issue that could cause to older, smaller drives.
Jason W:
Xine-xvesa is built this way as to not interfere with other Xine extensions, and same with Pysolfc. I needed a certain lib built a certain way for pysol to run so I just put it in the extenison itself to get loaded. And since pysol remains self contained into it's own directory, it works equally well with either python-2.5 or python-2.6 installed. When pysol is installed into /usr/local with it's installer, then it can only be used with the version of python it is installed with as it resides then under /usr/local/lib/python-version. I would rather avoid having to rebuild apps when library versions change when it is possible.
If you build a self contained application installed into it's own directory, you don't have to worry about it conflicting with other extensions and you can pack in needed libs that will not conflict with other versions of those libs in the repo. As we have seen the headache of dealing with and updating openssl versions, I am personally going to either build statically against openssl or include the openssl libs I built against into a special directory in the extenison and use LD_LIBRARY_PATH to find them in preference to /usr/local/lib. At least for small, simple apps. Not all apps take to upgrading patchlevels of openssl and if you include your ssl libs in your extension in a different directory than /usr/local, then you will never have to worry about openssl version changes. This works with apps, though I know that with libs like qt it is not so easy and would just have to use the version found in the standard path. Of course, this is not meaning that openssl will be built into it's own directory again, but that I will include the libs I built against in the extension itself to avoid future conflict and reduce the openssl dependency.
#Clarification, only apps that will never be used as a dependency of others, or there could be the issue of 2 ssl versions if there were libs bundled with a dependency. Packing ssl libs into an app that has dependencies that also rely on openssl is perhaps asking for trouble. Better to use the standard openssl extension as a dep or build statically.
This approach works well with the current tcz extension type, though it could also allow the simple mountable app that does not require it's files to be symlinked to the system. And to me probably the main advantage is being more independent of other extenisons in the repo and avoid having to rebuild the extension when lib X or Y is updated.
SamK:
Related comments on a similar topic:
http://forum.tinycorelinux.net/index.php?topic=5601.0
bigpcman:
--- Quote from: lucky13 on March 26, 2010, 08:59:25 PM ---PC-BSD also uses self-contained applications.
http://www.pcbsd.org/content/view/39/30/
It doesn't necessarily need to use a lot more memory/storage. It depends how many libraries are deemed "essential" and therefore in a base (whether in a distro's base or in some package) -- e. g., so that the most commonly needed GTK-related libs are either in the base or in one grand unified package rather than in separate packages. That would mean that some users would end up with certain unnecessary libraries (rather than the piecemeal approach which saves a marginal amount of space) just to use some small application built off some of those combined libraries. I always thought it would make more sense to bundle more of those kinds of things anyway, and IIRC that was one of the suggestions I made if DSL had gone to more of a rox-ish AppDir paradigm to get around the inode issue that could cause to older, smaller drives.
--- End quote ---
For those of us not completely aware of the linux library system here's some background:
http://www.innovationsts.com/blog/?p=1042
Navigation
[0] Message Index
[#] Next page
Go to full version