Re: [Pcbsd-pbi-dev] A new library handling idea

[Taras D. <go...@gm...>]

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 emp=
ty
> 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 t=
hey
> wont beable to be found anywhere else)
> ^ Generate an md5 sum of all the libraries in the DepLib folder and save =
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 prob=
lem
> of wasted memory, while still allowing
> things that dont have all the required libs in the system / the ones in t=
he
> 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)