Re: [Pcbsd-pbi-dev] A new library handling idea
Status: Beta
Brought to you by:
kmoore134
From: Federico L. <flo...@gm...> - 2006-02-14 14:10:07
|
NOO... you've got me all wrong :) EACH PBI will have a lib folder, for example /Programs/FooApp1.0/lib and /Programs/BarApp1.0/lib then when each program runs it will automatically clear the folder and create the symlinks. Sorry i can= t reply in more details but i'm a bit stripped for time now. Cheers On 2/13/06, Taras Danko <go...@gm...> wrote: > > Reading your message I got a few questions: > Lets imagine situation when user installs 2+ programs (from pbi), and > they use the same shared library. According to your algorythm the > first of those programms will not find a match of its specific > library in the /lib/ folder and will create a symlink to it there. > Then second prog during its installiation will find a match of its > specific library in the /lib/ folder and will not change anything. And > so on. > > Now lets imagine that user uninstalls the first app - will the > uninstall also remove the lib? Or the system will keep it forever > regardless of what progs are installed? Or maybe the system will check > if there is perhaps 1 app that refers to this lib - and if this is > FALSE - it will remove the lib? If so - it will be very similar to the > FreeBSD's dependency list... > > As I remember Kris wrote his thoughts about shared libraries at the > early days of PCBSD... He said that the advantages of the pbi (user > doesnt care about dependencies when installs a programm) are surpass > the disadvantages of multiple loading of shared objects... So its not > an unexpected news about this... > > Actualy as a programmer i can say that when you staticaly linking the > programm against some library using C/C++ compiller - the compiller > extracts only needed routines from the lib to add them to the > executable (similiar to the behavior, explained for the pascal > compiller by the guy before me ). But if we need a shared compiling - > there is also a way to decrease the shared object's size up to 1/3 of > its basic size - there are utilities called strippers for this purpose > ( dont recall the exact names right now ). > > By the way it will be useful to check the information of how another > OSes fixing this problem. For example Windows OS uses the same model > as pbi. Microsoft suggests third party developers to place their > shared libraries into their own folders but not to the global dirs > like system32 etc. It causes the situation with multiple loading of > the same libs, but it simplifies the developing of user apps for > developers... Eating the RAM it however causes the rapid growing of > number of applications available for this platform... > > IMHO the main dilemma of the pbi isnt a multiple loading of the same > libs, but is how to combine usual dependency system with pbi - in > other words - avoiding of the multiple installing of same > sub-tools(quick PBI example - apps "A" & "B" require app "C" as their > subsystem - "A" will install "C" to its subfolder or somewhere else, > "B" does the same. As a result "C" installed twice) > > If the information about programms installed via pbi system will be > added to the pkg list and newly installed programms will refer to them > as on dependecies - we'll lose the idea of pbi. If we will create a > kind of windows/macOS registry - it will start the complete separation > from original FreeBSD logic... > We'll really need a good software architector for this - because it is > hard to add something new to the existing schemes. ;-) > > Summarizing my long message i think it will be interesting to get > information from Mac users/coders on how does the MacOS act in same > situations since it is BSD based and also uses some of the Windows' > technics. > And also i think it will be cool to create a kind of official document > describing what to consider as specific or as global library / tool > when the developer creates its pbi or another soft for PCBSD (for > example should i consider required libc.so.6 as specific to my pbi > when the system has only libc.so.5 etc). Dont know how real is this > but it seems quite useful as for developer... > > > Regards, Taras aka Gorthaur > > > On 2/11/06, Federico Lorenzi <flo...@gm...> wrote: > > Ok, heres a brand new idea on handaling libraries: > > > > Directory structure: > > PBI Root > > -> ProgLib > > -> libfoo.so.1 > > -> DepLib > > -> libc.so.6 > > -> libqt.so.2 > > -> libkde.so.8 > > -> lib > > <empty> > > > > We have a PBI called FooApp, which needs libc.so.6 libqt.so.2 > libkde.so.8 > > and libfoo.so.1 > > Now, libfoo.so.1 is a program specific library, NOT a normal dependancy= , > (it > > comes with FooApp), > > so it is stored in ProgLib, while the other libs are stored in > DepLib.... > > Now heres the killer bit... > > > > The lib path of the program will be set to the lib dir, but since its > empty > > a few things will happen first... > > A script (which i'm working on) will: > > * Symlink all the libraries in the ProgLib folder to the lib folder (as > they > > wont beable to be found anywhere else) > > ^ Generate an md5 sum of all the libraries in the DepLib folder and sav= e > it > > as DepLib/md5 (once off) > > * Compare those md5's to that of the systems libraries, if theres a > match, > > the system ones get symlinked into the > > lib folder, but if theres no match, the DepLib ones get symlinked in > > > > Please tell me what you think of this idea, as it should elivate the > problem > > of wasted memory, while still allowing > > things that dont have all the required libs in the system / the ones in > the > > system are too out of date / too new to > > still work! > > > > PS. The DepLib and ProgLib folders tie in with my ports-pbi > compatability > > plan ;) > > Cheers > > > -- > contact me: > email: go...@gm... > com...@us... > icq: 166956956 > mobile: +380969474990 (djuice) > |