############################################################################## # Document: aaa_elflibs.txt # Purpose : Explain why Slackware's aaa_elflibs should not be upgradepkg'd # Author..: Stuart Winter # Date....: 26-Jan-2005 # # Based on the usenet thread I answered: # http://groups-beta.google.com/group/alt.os.linux.slackware/browse_frm/thread/f2b53897d1614b93 # This was slightly before the release of Slackware-10.1 ############################################################################## Here is what Pat says about aaa_elflibs (slightly edited) some time ago. I hope this helps explain the purpose of aaa_elflibs and answers the question of why it should not be upgraded. [..] Of course, aaa_elflibs (kludgey as it is) contains a few nuggets that really aren't found anywhere else. I've also been meaning to warn people that if they see a new aaa_elflibs released that upgrading to it is a REALLY DUMB IDEA. The aaa_ packages are intended for one time installation (though reinstalling aaa_base is a lot safer than reinstalling aaa_elflibs). aaa_elflibs is mostly to provide a net for people who would otherwise install a functionally incomplete system to cut down on the amount of help people need if they do not install required packages. It wouldn't be such a bad package except that some projects (like, say CUPS, or ALSA) don't tend to increment library versions when they release new ones, so ancient ones in aaa_elflibs get copied over new ones, and things begin to mysteriously fail. Fun, huh? I've been meaning to look at a solution, but previous attempts like staging libraries from /lib/incoming and considering if they should be installed had other problems. A nice side effect of the filename collisions is that having something listed in aaa_elflibs also prevents removing the newer library when people run around removing things at random so they can have 60GB free instead of 59GB ;-) [..] To answer the question about why aaa_elflibs is not mentioned in UPGRADE.TXT: if you're upgrading every package in the OS, then there is no need to worry about aaa_elflibs because its library *version* numbers are identical to those contained within the main packages. For example: turrican [a] # tar ztvvf aaa_elflibs-10.1.0-i486-1.tgz | grep curses.so -rwxr-xr-x root/root 253584 2005-01-24 17:02:29 lib/libncurses.so.5.4 turrican [a] # tar ztvvf ../l/ncurses-5.4-i486-2.tgz|grep curses.so -rwxr-xr-x root/root 253600 2004-02-17 23:22:33 lib/libncurses.so.5.4 turrican [a] # This is why it is not mentioned in the UPGRADE.TXT. A short while ago, elflibs was renamed to aaa_elflibs (the name it now has) so that it would always be installed prior to any other packages. This was so that if you were installing Slackware-current then you wouldn't run into the situation in the following example: a/aaa_elflibs contains bzip2 libraries from a/bzip2 Because the packages are installed according to their alphabetic precedence, it meant that bzip2 would be installed first. Remembering that aaa_elblibs (or 'elflibs' as it was called previously) was only updated right before a new release of Slackware, you run into the problem, or run the risk that the installation goes like this: - a/bzip2 is installed -- this is the very latest bzip2 - - elflibs package is installed This package has not been updated since the last release of Slackware it contains ancient libraries -- including an old copy of bzip2's .so. It was renamed 'aaa_elflibs' to work around this problem. This also explains why you should not upgradepkg aaa_elflibs *without* also upgrading the entire OS. The short version: one who is running Slackware-current should upgrade everything *but* aaa_elflibs because aaa_elflibs will (up until a few days ago) have contained libraries from when Slackware 10 was first released.