1 |
On Friday 11 December 2009 11:11:41 Helmut Jarausch wrote: |
2 |
> Hi, |
3 |
> |
4 |
> I'm curious how portage solves its most difficult part (in my eyes). |
5 |
> |
6 |
> When installing a dynamic library (by "hand") I have often got an |
7 |
> error messages if the corresponding library is currently in use. |
8 |
> |
9 |
> How does portage succeed anyway. |
10 |
> (I have the suspicion that it does not succeed always, since sometimes |
11 |
> only rebooting solves some very strange problems) |
12 |
> |
13 |
> How to replace fundamental X11-libaries on a system running X11 |
14 |
> or even more suprising, how can I replace a running glibc ? |
15 |
> |
16 |
> Many thanks for enlightening me, |
17 |
> Helmut. |
18 |
> |
19 |
|
20 |
Portage does nothing special, as dealing with this is a Unix thing. |
21 |
|
22 |
On Unix, the inode is the file, not the directory entry. If you want to |
23 |
replace an open file, the system simply does it and updates the dentry to |
24 |
point to a new inode. Any spp using the old file will continue to use it as it |
25 |
still has a handle to the inode. The inode is only fully deleted when the last |
26 |
app using it closes it |
27 |
|
28 |
If you update a library to a new version with an API break, the lib should get |
29 |
a new soname so the file is a different name, hence no collision (symlinks to |
30 |
libraries excepted). |
31 |
|
32 |
This is how it should work, any code that tries to do it a different way is by |
33 |
definition broken, that's why portage needs take no special measures. |
34 |
|
35 |
All of this is in complete contrast to other broken systems, such as Windows |
36 |
for example. On Windows, the filename IS the file, so upgrades are horrible. |
37 |
Installers must put the file somewhere else and have the final steps and |
38 |
registry updates done at next reboot before anything has a chance to open |
39 |
libs. This is why fairly deep updates on Windows often require multiple reboot |
40 |
- multiple apps installed multiple libs to be fiddled with multiple times .... |
41 |
|
42 |
|
43 |
-- |
44 |
alan dot mckinnon at gmail dot com |