##############################################################################
# Document: aaa_elflibs.txt 
# Purpose : Explain why Slackware's aaa_elflibs should not be upgradepkg'd 
# Author..: Stuart Winter <mozes@armedslack.org>
# 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
   - <more packages installed>
   - 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.

###############################################################################
# Document: aaa_elflibs.txt 
# Purpose : Explain how to manage Slackware's aaa_elflibs package
# Author..: Stuart Winter <mozes@slackware.com>
# Date....: 22-Mar-2015
# Version : 1.02
###############################################################################
# Change log
# 22-Mar-2015
# * Added information about security updates.
# * Mentioned the other purpose of aaa_elflibs - bootstrapping during OS 
#   installation.
# 17-Mar-2015
# * Added more info/summaries from Pat.
# * Removed old (now incorrect) information.
# 26-Jan-2005
# * Created.
###############################################################################

Purpose of aaa_elflibs
======================

1.  It's mostly to provide a net for people who would otherwise install a
    functionally incomplete system.  It's to cut down on the amount of help
    people need if they do not install required packages.

2.  Bootstraps the OS installation.  Some of the package post installation 
    scripts execute binaries that are linked to (for example) the openssl
    library.  If the openssl package has not yet been installed on to the
    target then the binary will fail to execute.  Immediately populating the
    target's root file system with the required binaries allows the packages
    to install correctly.  The 'aaa_elflibs' package was originally called 
    'elflibs' but in order to prevent this problem entirely, it was renamed so
    that it'd be installed as one of the first packages!

3.  Aids with evolution in Slackware-current.  Not all packages can be or are
    rebuilt against a new version of a hard dependency (library) in one change
    batch.  Therefore aaa_elflibs will contain the previous version and the new
    version so that the packages that depend upon the old version will continue
    working.

Upgrading aaa_elflibs
=====================

Previous advice had been that aaa_elflibs was for one-time installation and
should never be upgraded.  This is no longer the case.


Stable Slackware releases
``````````````````````````

1. On a stable release of Slackware, you should _not_ upgrade to an aaa_elflibs
   from _-current_.

2. For Stable releases of Slackware, you should always upgrade aaa_elflibs to
   the version that is contained within the release that you're upgrading to.
   You may have problems if you do not upgrade aaa_elflibs as part of your OS
   upgrade if some packages (provided by Slackware or a 3rd party) require older
   versions of libraries.
   When performing the OS upgrade, you should upgrade aaa_elflibs first.

Slackware current branch
````````````````````````

3. You should not upgrade aaa_elflibs in -current that's old and stale _after_
   other upgrades.
   For example: if aaa_elflibs was updated two months ago in -current, but you
   skipped it and upgraded other packages, you should not go back and upgrade to
   that aaa_elflibs because there is a possibility that it'll downgrade to
   previous versions of libraries.  This is because some packages such as CUPS
   do not version their library file names.

4. Upgrading to the latest aaa_elflibs in Slackware -current _in order_ (e.g. 
   not falling foul of item 3 above) never harms anything, unless you're running
   running some developmental version of Slackware (and have gone off the rails)
   or have replaced Slackware system libraries with local upgrades.

   The other reason that you should upgrade aaa_elflibs in -current 
   _and in the correct order_ is because aaa_elflibs may be carrying some
   recently deprecated libraries that are required until the packages using them
   have been recompiled.
   For example, readline had been upgraded and the soname had changed.  awk
   (and many others) relied upon that old soname, but had not been recompiled.
   aaa_elflibs had been rebuilt to include the previous version of readline and
   the newer one, so that awk et al would continue working.



I can't think of any case where you shouldn't upgrade aaa_elflibs, unless you've
skipped other upgrades or upgraded some things manually.

Security updates to aaa_elflibs
===============================

The usual advice is to do a full installation of Slackware which means that the
bundled versions of aaa_elflibs are mostly owned by the packages from which
the libraries were extracted.

If you did not install all of the packages, you can keep atop of security updates
by upgrading and installing any _new_ packages within the 'patches' directory of
the stable Slackware release that you're using.
This is the _easiest way_, although would install some packages which were not
previously installed nor part of the aaa_elflibs package:

Example:

  # cd slackware64-14.1/patches/packages 
  # upgadepkg --install-new *.t?z

The other way is to only upgrade/install the patches that are relevant.
This means that you need to determine what packages comprise aaa_elflibs.
The Slackware ARM port has such a list that is used to build its aaa_elflibs package.
This list is automatically generated by extracting the Slackware x86_64 aaa_elflibs
package and parsing its slackware64/MANIFEST.bz2 to determine which package
owns the libraries.

  # cd /tmp
  # wget ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/a/aaa_elflibs/x86_slackware_aaa_elflibs_pkg_list.txt
  # cut -d: -f1 x86_slackware_aaa_elflibs_pkg_list.txt|rev| cut -d- -f4-|rev|sort|uniq
 ./a/acl
 ./a/attr
 ./a/bzip2
 ./a/cups
 ./a/gpm
 ./a/lvm2
 ./a/sysfsutils
 ./a/xz
 ./ap/dmapi
 ./d/gcc
 ./d/libtool
 ./l/alsa-lib
 ./l/db42
 ./l/db44
 ./l/expat
 ./l/freetype
 ./l/fuse
 ./l/gdbm
 ./l/glib2
 ./l/gmp
 ./l/libcap
 ./l/libelf
 ./l/libidn
 ./l/libjpeg
 ./l/libpng
 ./l/libtermcap
 ./l/libtiff
 ./l/libusb
 ./l/libusb-compat
 ./l/mm
 ./l/mpfr
 ./l/ncurses
 ./l/pcre
 ./l/popt
 ./l/readline
 ./l/slang
 ./l/slang1
 ./l/svgalib
 ./l/zlib
 ./n/curl
 ./n/openldap-client

As mentioned previously, the aaa_elflibs package also contains some libraries
(typically older versions) that are no longer present in the Slackware
packages.

  # cd /tmp
  # wget ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/a/aaa_elflibs/x86_slackware_aaa_elflibs_onlyhost_list.txt
  # cat x86_slackware_aaa_elflibs_onlyhost_list.txt
lib/libgpm.so.1.19.0
usr/lib/libgmp.so.3.4.4
usr/lib/libhistory.so.5.2
usr/lib/libjpeg.so.62.0.0
usr/lib/libltdl.so.3.1.6
usr/lib/libpcre.so.0.0.1
usr/lib/libreadline.so.5.2

If you were particularly concerned about these not receiving security updates, 
you could move them elsewhere or delete them.  Prior to doing so you should
check whether anything on your installed OS uses them. Doing so is beyond the
scope of this document.

-- 
Stuart Winter <mozes@slackware.com>