Я только что обновил на старом компе перекомпилированный под athlon-xp glibc.
И glibc-solibs, естественно не обновлял, будучи уверенным, что всё равно glibc перезапишет файлы пакета glibc-solibs.

Если версия та же, а изменялись только ключи configure и/или CFLAGS/CXXFLAGS, то перезапишет (ведь имена файлов получатся теми же самыми), и числиться эти файлы будут за обоими пакетами, и установленный glibc-solibs не даст удалить критичные библиотеки.
А если версия другая настолько, что .so получились с другими именами, тогда есть смысл 1) сделать -solobs соответствующей версии и 2) разобраться с символьными ссылками на библиотеки (см. doinst.sh).

Если появились вопросы, с удовольствием отвечу.

Пример понятен, только я как "Фома неверующий" поищу этот участок кода в скрипте.
Когда понятен механизм, многие вопросы отпадают сразу сами.
Я только что обновил на старом компе перекомпилированный под athlon-xp glibc.
И glibc-solibs, естественно не обновлял, будучи уверенным, что всё равно glibc перезапишет файлы пакета glibc-solibs.
А вопросы ещё будут, обязательно. Вы очень хорошо объясняете, обращая внимание на неожиданные стороны проблемы.
Я потихоньку "созреваю" для lfs...
Естественно, только с pkgtool в качестве завхоза. 
Так что вопросы будут.

# mkdir -p /tmp/package-test/home/test; cd /tmp/package-test
# echo file1 > home/test/file1
# echo file2 > home/test/file2
# makepkg -c y /tmp/test-0.1-noarch-1.txz
...
Slackware package ../test-0.1-noarch-1.txz created.

# rm home/test/file2
# makepkg -c y /tmp/test-part-0.1-noarch-1.txz
...
Slackware package /tmp/test-part-0.1-noarch-1.txz created.

# installpkg /tmp/test-part-0.1-noarch-1.txz
# find /home/test
/home/test/
/home/test/file1

# installpkg /tmp/test-0.1-noarch-1.txz
# find /home/test
/home/test/
/home/test/file1
/home/test/file2

# removepkg test
Removing package /var/log/packages/test-0.1-noarch-1...
Removing files:
  --> /home/test/file1 was found in another package. Skipping.
  --> Deleting /home/test/file2

# find /home/test
/home/
/home/test/
/home/test/file1

# removepkg test-part
Removing package /var/log/packages/test-part-0.1-noarch-1...
Removing files:
  --> Deleting /home/test/file1
  --> Deleting empty directory /home/test/

Если появились вопросы, с удовольствием отвечу.

Пакеты -solibs -- это такой довесок по аналогии с aaa_elflibs, который может быть необязательным для системы, но позволяет экономить место, не ставя крупный родительский пакет.

Если на конкретной системе ПО не собирают, а ставят из готовых бинарных пакетов, на ней не нужен glibc, достаточно glibc-solibs (а если нет ПО, динамически связанного с glibc, то не нужен и glibc-solibs). Для парка систем достаточно одной сборочной машины.

Теперь разница видна лучше? Экономия на 2,6Мб против 12,0Мб пакета или всё же на 11Мб против 141Мб в системе?

Баста, приехали, сломалось всё! А вот если glibc-solibs установлен, всё по-прежнему работает

Вот этого я понять как раз и не могу. Ерунда какая то получается.
Есть два пакета - А и Б.
В пакет А входит файл a, а в пакет Б входят фаилы a, b и c...
И их установили поочерёдно - сначала А, потом Б.
Каким образом можно удалить пакет Б, с помощью примитивного по сути pkgtool, чтобы он не трогал файл a?
Я думаю, дело обстоит по другому.
Патрик, ради минимизации размера каталога /a, сделал пакет с необходимым минимумом от glibc, обеспечивающий работоспособность системы пакетов в каталоге /a.
При расширении системы, glibc-solibs "перекрывается" полным пакетом glibc!
И удаление невозможно без ущерба для работоспособности, а вот обновление - пожалуйста.
Так что glibc-solibs нужен только если нужна только базовая систем из каталога /a.
Другого я объяснения не вижу.

Все файлы из этого пакета входят в основной пакет glibc. Видимо поэтому разработчики SalixOS исключили пакет из установочного набора пакетов.

А теперь представьте, всё уже собрано (или теперь будет собираться на другой машине), толстенный пакет glibc больше не нужен, делаете "removepkg glibc" и... Баста, приехали, сломалось всё! А вот если glibc-solibs установлен, всё по-прежнему работает (это и есть основная задача пакетов -solibs, обеспечение работоспособности в отсутствие толстых девелоперских пакетов).

-solibs пакеты содержат только .so и не содержат дополнительных файлов по отношению к родительским пакетам (которые нужны для сборки), но позволяют сохранить работоспособность на случай полного удаления серии D. Поэтому -solibs лучше включать.

Все файлы из этого пакета входят в основной пакет glibc. Видимо поэтому разработчики SalixOS исключили пакет из установочного набора пакетов.

Кроме того, нужно понимать, что библиотеки обычно позволяют как статическое связывание, когда необходимая часть кода библиотеки внедряется в исполняемый код программы, так и динамическое связывание (линковку), когда во время исполнения общий код (so -- shared object) должен быть доступен. Причём во втором случае возможно также 2 варианта, когда связывание производится в момент загрузки бинарника (стандартный вариант, в этом случае при отсутствии нужного .so бинарник просто не будет загружен в память, загрузчик выведет сообщение об отсутствующей динамической библиотеке), или когда приложение самостоятельно открывает .so (обычно именно так подключают дополнительные плагины).

Статически собранный бинарник хорош тем, что самодостаточен. Плох своим размером, а также тем, что при обновлении библиотеки, например, по причине обнаружения в ней уязвимостей, бинарники, статически связанные с ней, нужно пересобирать.
Искусство -- в нахождении компромисса в подходах.

ps.

http://slackware.ponce.cc/blog/2010/08/ … th-sbopkg/
В сухом остатке:

# cat <<EOF > /var/lib/sbopkg/queues/lxde.sqf
leafpad
xarchiver | BEND_ME_OVER=kthxbai
openbox
xmms2
gpicview
lxappearance
lxappearance-obconf
lxde-common
lxrandr
lxterminal
menu-cache
lxmenu-data
lxlauncher
lxpanel
lxpanel-xmms2
lxtask
lxpolkit
lxsession
lxsession-edit
vala
libfm
pcmanfm
lxshortcut
lxinput
lxmusic
lxdm
libgee
gksu-polkit
EOF
# sbopkg -Rri lxde.sqf

наличие .so еще не делает доступны сами утилиты, например, без установки пакета bzip2 сами команды из него не доступны, но то, что слинковано с libbzip.so уже будет иметь зависимость установленной и будет работоспособно.

По этому поводу такой вопрос.
Я так понимаю, есть два вида зависимостей - прямая и относительная. Прямая, это когда пакет использует какую то библиотеку из другого пакета и работать без этого физически не может.
Но есть ещё такая штука, пример - vlc медиапакет. При компиляции требует множество "установленных" пакетов, но скомпилированный уже, не требует их наличия в системе.
Я это назвал для себя относительной зависимостью. Интересует механизм этого действия. Конкретное примененение - желание скомпилировать DE LXDE на системе, где сам LXDE не установлен.

То есть, если на системе не нужно ничего собирать, то вместо вон тех пакетов достаточно одного aaa_elflibs, в нем собраны .so из тех пакетов.

Очень ценные замечания. (включая все Ваши посты)
Спасибо!
У меня многое получается как то интуитивно, Ваши же пояснения ставят всё на свои места.
Озвучиваете то, что я никак не могу собрать "в кучку"...
Просто стимулируете заниматься своим хобби...
Не сочтите за лесть, но приятно, когда тебя замечают и помогают. 

$ grep -Rlf <(grep \.so /var/log/packages/aaa_elflibs-14.0-x86_64-4) /var/log/packages | sort
/var/log/packages/aaa_elflibs-14.0-x86_64-4
/var/log/packages/acl-2.2.51-x86_64-1
/var/log/packages/alsa-lib-1.0.26-x86_64-1
/var/log/packages/attr-2.4.46-x86_64-1
/var/log/packages/bzip2-1.0.6-x86_64-1
/var/log/packages/cups-1.5.4-x86_64-2
/var/log/packages/db42-4.2.52-x86_64-3
/var/log/packages/db44-4.4.20-x86_64-3
/var/log/packages/dmapi-2.2.10-x86_64-1
/var/log/packages/expat-2.0.1-x86_64-2
/var/log/packages/fuse-2.8.5-x86_64-1
/var/log/packages/gcc-4.7.1-x86_64-1
/var/log/packages/gdbm-1.8.3-x86_64-4
/var/log/packages/glib2-2.32.4-x86_64-1
/var/log/packages/gmp-5.0.5-x86_64-1
/var/log/packages/gpm-1.20.1-x86_64-5
/var/log/packages/libcap-2.22-x86_64-1
/var/log/packages/libelf-0.8.13-x86_64-2
/var/log/packages/libidn-1.25-x86_64-2
/var/log/packages/libjpeg-v8a-x86_64-1
/var/log/packages/libpng-1.4.12-x86_64-1
/var/log/packages/libtermcap-1.2.3-x86_64-7
/var/log/packages/libtiff-3.9.6-x86_64-1
/var/log/packages/libtool-2.4.2-x86_64-1
/var/log/packages/libusb-1.0.9-x86_64-1
/var/log/packages/libusb-compat-0.1.4-x86_64-1
/var/log/packages/lvm2-2.02.96-x86_64-4
/var/log/packages/mm-1.4.2-x86_64-2
/var/log/packages/ncurses-5.9-x86_64-1
/var/log/packages/openldap-client-2.4.31-x86_64-2
/var/log/packages/pcre-8.12-x86_64-1
/var/log/packages/popt-1.7-x86_64-3
/var/log/packages/readline-5.2-x86_64-4
/var/log/packages/slang1-1.4.9-x86_64-1
/var/log/packages/slang-2.2.3-x86_64-1
/var/log/packages/svgalib-1.9.25-x86_64-2
/var/log/packages/sysfsutils-2.1.0-x86_64-1
/var/log/packages/xz-5.0.4-x86_64-1
/var/log/packages/zlib-1.2.6-x86_64-1

То есть, если на системе не нужно ничего собирать, то вместо вон тех пакетов достаточно одного aaa_elflibs, в нем собраны .so из тех пакетов.

vam/tagi/a/tagfile
aaa_elflibs: SKP

Зря. Нужно объяснять, почему для него лучше ADD?

Старые библиотеки, используемые некоторыми старыми программами?
Добавлю для себя.
Здесь теги перекочевали прямо из SalixOS, я ещё не просматривал попакетно.
Спасибо за подсказку.

Зря. Нужно объяснять, почему для него лучше ADD?

2)

-solibs пакеты содержат только .so и не содержат дополнительных файлов по отношению к родительским пакетам (которые нужны для сборки), но позволяют сохранить работоспособность на случай полного удаления серии D. Поэтому -solibs лучше включать.

Скачать пакет slackware-14.0_tags.tar.bz2 .

Если кому интересно, могу описать как интегрировать свои каталоги в инсталляционный дистрибутив на примере каталогов /extra и /lxde.
Но это уже отдельная история.
Хотелось бы ещё "подчистить" каталог /n.
Лично мне от сети нужно только подключение по dhcpcd и wifi. ВСЕ!!!
Не хочу, чтобы у меня мертвым грузом лежали на винте пакеты, которые я не использую.
Если уж нужен будет какой либо пакет, лучше добавить его осознанно, заодно узнав для чего он нужен.
Вот и все, чем я хотел поделиться.
Приветствуются советы, пожелания, замечания.