portage-2.2 preserve-libs FEATURES explained
Maybe I am not the right person to write about it. But I felt the necessity to write about it. So I will just write something about preserve-libs, leaving other FEATURES to more competent people.
Portage-2.2 has already entered unstable tree. Many people has started using it. It has many new features, like preserve-libs, sets, license filter and so on. Please check README and RELEASE-NOTES for a complete list. I will only talk about preserve-libs.
To understand why we need it, we have to know some background information.
First of all, applications are not built from scratch. Any non trivial apps use lot of libraries.
In GNU/Linux, most of them are shared libraries, i.e. .so files.
You can use `ldd /usr/bin/mplayer` to check what shared libraries an app has been linked to, replace mplayer to whatever program you'd like to check.
Shared libraries have versions.
E.g. /usr/lib/libavformat.so.51, here 51 denotes its version.
After upgrading, the version number may change.
E.g. /usr/lib/libavformat.so.52
Previously in Gentoo Linux, after upgrading, old version of so file will be deleted.
As a consequence, all the apps which have previously been linked to the old so file will cease to work.
The most well known case may be "XML::Parser perl module not found".
At that time, to solve this problem, you would have to use revdep-rebuild to rebuild all such apps.
Before they are rebuilt, you can't use them.
I myself have experienced this a lot, especially on mplayer.
Sometimes, a soccer match is about to kick off, suddenly I found my mplayer not working because of a missing old so file.
Now, the nightmare is all over.
With preserve-libs, your apps will continue to work, because old so files are preserved.
And they will not stay on your hard disk forever.
After `emerge @preserved-rebuild` they will be all gone and your apps will be linked to the new version of so file.
Such a wonderful world~~~
The following is from the output of a recent system upgrade:
!!! existing preserved libs:
>>> package: sys-libs/glibc-2.8_p20080602
* - /lib/libm-2.7.so
>>> package: www-client/mozilla-firefox-3.0-r1
* - /usr/lib/mozilla-firefox/libgfxpsshar.so
* - /usr/lib/mozilla-firefox/libgkgfx.so
* - /usr/lib/mozilla-firefox/libgtkembedmoz.so
* - /usr/lib/mozilla-firefox/libgtkxtbin.so
* - /usr/lib/mozilla-firefox/libmozjs.so
* - /usr/lib/mozilla-firefox/libxlibrgb.so
* - /usr/lib/mozilla-firefox/libxpcom.so
* - /usr/lib/mozilla-firefox/libxpcom_compat.so
* - /usr/lib/mozilla-firefox/libxpcom_core.so
>>> package: sys-devel/libtool-2.2.4
* - /usr/lib/libltdl.so.3
* - /usr/lib/libltdl.so.3.1.6
>>> package: media-video/ffmpeg-0.4.9_p20080326
* - /usr/lib/libavformat.so.51
* - /usr/lib/libavformat.so.51.12.1
Use emerge @preserved-rebuild to rebuild packages using these libraries
Now I have both old and new versions of libavformat.so
$ ls /usr/lib/libavformat.so.5*
/usr/lib/libavformat.so.51 /usr/lib/libavformat.so.51.12.1 /usr/lib/libavformat.so.52 /usr/lib/libavformat.so.52.12.0
And my mplayer is still working.
Portage-2.2 has already entered unstable tree. Many people has started using it. It has many new features, like preserve-libs, sets, license filter and so on. Please check README and RELEASE-NOTES for a complete list. I will only talk about preserve-libs.
To understand why we need it, we have to know some background information.
First of all, applications are not built from scratch. Any non trivial apps use lot of libraries.
In GNU/Linux, most of them are shared libraries, i.e. .so files.
You can use `ldd /usr/bin/mplayer` to check what shared libraries an app has been linked to, replace mplayer to whatever program you'd like to check.
Shared libraries have versions.
E.g. /usr/lib/libavformat.so.51, here 51 denotes its version.
After upgrading, the version number may change.
E.g. /usr/lib/libavformat.so.52
Previously in Gentoo Linux, after upgrading, old version of so file will be deleted.
As a consequence, all the apps which have previously been linked to the old so file will cease to work.
The most well known case may be "XML::Parser perl module not found".
At that time, to solve this problem, you would have to use revdep-rebuild to rebuild all such apps.
Before they are rebuilt, you can't use them.
I myself have experienced this a lot, especially on mplayer.
Sometimes, a soccer match is about to kick off, suddenly I found my mplayer not working because of a missing old so file.
Now, the nightmare is all over.
With preserve-libs, your apps will continue to work, because old so files are preserved.
And they will not stay on your hard disk forever.
After `emerge @preserved-rebuild` they will be all gone and your apps will be linked to the new version of so file.
Such a wonderful world~~~
The following is from the output of a recent system upgrade:
!!! existing preserved libs:
>>> package: sys-libs/glibc-2.8_p20080602
* - /lib/libm-2.7.so
>>> package: www-client/mozilla-firefox-3.0-r1
* - /usr/lib/mozilla-firefox/libgfxpsshar.so
* - /usr/lib/mozilla-firefox/libgkgfx.so
* - /usr/lib/mozilla-firefox/libgtkembedmoz.so
* - /usr/lib/mozilla-firefox/libgtkxtbin.so
* - /usr/lib/mozilla-firefox/libmozjs.so
* - /usr/lib/mozilla-firefox/libxlibrgb.so
* - /usr/lib/mozilla-firefox/libxpcom.so
* - /usr/lib/mozilla-firefox/libxpcom_compat.so
* - /usr/lib/mozilla-firefox/libxpcom_core.so
>>> package: sys-devel/libtool-2.2.4
* - /usr/lib/libltdl.so.3
* - /usr/lib/libltdl.so.3.1.6
>>> package: media-video/ffmpeg-0.4.9_p20080326
* - /usr/lib/libavformat.so.51
* - /usr/lib/libavformat.so.51.12.1
Use emerge @preserved-rebuild to rebuild packages using these libraries
Now I have both old and new versions of libavformat.so
$ ls /usr/lib/libavformat.so.5*
/usr/lib/libavformat.so.51 /usr/lib/libavformat.so.51.12.1 /usr/lib/libavformat.so.52 /usr/lib/libavformat.so.52.12.0
And my mplayer is still working.
Comments
It looks especially useful for new users, who are not always aware of revdep-rebuild (and complain that updates break their systems), and administrators of important systems, who may just forget from time to time. If a daemon needs to be rebuilt, it will manifest badly on the next reboot. ;-)
Are applications scanned on every emerge? Is there a cache or tree of installed packages with .so version metadata?
The main problem is dependency tracking which dpkg rpm handles in almost perfect level. This is reported as bug #1991 in 2002 (6 years ago) http://bugs.gentoo.org/show_bug.cgi?id=1991 .
This problem isn't fixed and then suggested workaround (revdev-rebuild). Which introduces new problems http://code.google.com/soc/2008/gentoo/appinfo.html?csaid=93F051D573756C5A
Another workaround is leave files on disk.
This requires a lot of human/administrator/user work hour to upgrade system. (This is because user must read all messages issued by update process and check what "orders" upgrade system order user to execute. And user doesn't have any option to chose (except these: no upgrade, and no follow orders, but both leads to same: Your system is out of sync, and You can't install new packages).
In debian system upgrade can be done in seconds automatically.
!!! existing preserved libs:
>>> package: kde-base/kdelibs-3.5.10
* - /usr/kde/3.5/lib/libartskde.so.1
* - /usr/kde/3.5/lib/libartskde.so.1.2.0
Use emerge @preserved-rebuild to rebuild packages using these libraries
and when i after `emerge @preserved-rebuild`, this message is showing again!
i list these two lib by `ls -al libartskde*`
lrwxrwxrwx 1 root root 19 2008-09-18 17:04 libartskde.so.1 -> libartskde.so.1.2.0
-rwxr-xr-x 1 root root 326044 2008-02-24 20:49 libartskde.so.1.2.0
this seems these two libarys are linked together. is there any wrong with this?