Linked by Thom Holwerda on Tue 14th Feb 2006 22:25 UTC
Permalink for comment 95801
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



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)