To view parent comment, click here.
To read all comments associated with this story, please click here.
Actually, I think we can have best of both worlds here. What needs to be done is to clarify what belongs to the "base system" (in good FreeBSD tradition) - and make PBI creator skip those libraries that we can expect to be present on all PC-BSD installs.
Ring 0 would be FreeBSD base system + xorg and all their dependencies. Kdelibs, qt, and kdebase might go there as well, with all its dependencies. If you think in an integrated solution (KDE part as the OS for instance) - users will have at least that on each PC-BSD install. And if you come to think of it: FreeBSD + xorg (server, libs, fonts, etc.) + kdebase + qt + kdelibs = that pretty much covers the majority (wild speculation: 70-90%) of all shared libraries you'll ever need for your PBIs. Which means the "overhead" (in memory for instance) is either minimal or non existent (pretty much all "independent" kde apps - scribus, kdissert, tellico, k3b - these are just the ones I use - will be satisfied without any additional libs in the PBI 




Member since:
2006-01-16
I agree with him on the .PBI problem. Their solution to "library hell" is to bring all libraries with you in the .PBI and put them in local-per-program subdirectory for each program. This has 2 consequences:
1. Programs which PRODUCE other programs (compilers/IDE combos etc.) will work but their "product" won't because it won't find the required libraries.
2. Memory usage will grow as there will be many instances of the same (or slightly version different) library per each program. This is actualy braking the usefulness of .so altogether.
This is not just some random rant, I am writing this from PCBSD and I also contributed one .PBI myself (Lazarus)
I think however that the .PBI concept is nice for "end-user" apps which don't "provide" (typical is openoffice or firefox) but not for programs which "produce" something which needs a framework. I think that putting all possible(or most atleast) frameworks through ports and then using end apps via .PBI might be the best solution with possibility of combined checking or atleast one way (so a PBI can see if it has the libs and if not, will install a pkg which it has with itself)