Slackware 14 minimal install

Многие пользователи "заболевают" желанием установить систему в минимальной комплектации, чтобы затем самому наращивать ее, путем добавления только нужных пакетов.
Тем самым, держа систему под контролем и предотвращая превращение системы в захламленную "кладовку".
Не избежал этой эпидемии и я.
Мне нужна была минимальная работоспособная система, чтобы сразу после установки я смог выйти в интернет и начать доустанавливать только нужные мне пакеты.
В качестве DE я выбрал LXDE, то есть с дистрибутива были установлены пакеты из каталогов /a /ap /d /l /n /x...
Еще в дистрибутив были добавлены каталоги /extra и /lxde. Но это уже дополнение, в котором пакеты не входящие в официальный дистрибутив, такие как lxde, шрифты и aspell-ru, собранный предварительно google-chrome...
За прообраз был взят дистрибутив SalixOS-XFCE-14.0. Список устанавливаемых пакетов из каталогов /core и /basic.
Затем были добавлены некоторые пакеты для работоспособности браузера google-chrome.
Прилагаю архив с тегами для установки минимальной системы дистрибутива Slackware-14.0.

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

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

1)

vam/tagi/a/tagfile
aaa_elflibs:SKP

vam/tagi/a/tagfile
glibc-solibs:SKP
vam/tagi/a/tagfile
glibc:ADD

bormant написал:

vam/tagi/a/tagfile
aaa_elflibs: SKP

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

Нет, не старые. Это сборник "обычно нужных .so" из других пакетов. Каких? А вот этих (кроме aaa_elflibs):

$ 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 из тех пакетов.

bormant написал:

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

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

Возвращаясь к aaa_elflibs -- обратите внимание, он никогда потом в дистрибутиве не обновляется (в patches), если не считать обновления на следующий выпуск дистрибутива. Так сделано, чтобы он не затер своими, возможно уже устаревшими, версиями .so те, что установлены позже с обновленными пакетами. Ах да, наличие .so еще не делает доступны сами утилиты, например, без установки пакета bzip2 сами команды из него не доступны, но то, что слинковано с libbzip.so уже будет иметь зависимость установленной и будет работоспособно.
Состав aaa_elflibs от версии к версии корректируется, чтобы обеспечить как можно больше наиболее необходимых зависимостей для прочих пакетов.
Отчасти, это один из слакваревых вариантов уменьшения связности пакетов.

bormant написал:

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

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

Есть сборочные зависимости (пакеты, необходимые только для сборки и не требующиеся для выполнения) и зависимости времени выполнения.

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

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


ps.

"cdrw⇓" написал:

скомпилировать DE LXDE на системе, где сам LXDE не установлен.

# 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

"bormant⇓" написал:

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

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

"cdrw⇓" написал:

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

"bormant⇓" написал:

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

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

cdrw,
pkgtools (в частности installpkg/upgradepkg/removepkg) не настолько примитивны, как вы о них думаете. removepkg не удаляет файл с диска до тех пор, пока есть хоть один пакет, содержащий файл (по имени, включая полный путь).
Да, если разные пакеты ставят по одному имени _разные_ файлы -- такая ситуация специально не отслеживается, выживает последний из установленных.

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

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

"cdrw⇓" написал:

Я думаю, дело обстоит по другому.

PACKAGE NAME: glibc-solibs-2.15-x86_64-7
COMPRESSED PACKAGE SIZE: 2.6M
UNCOMPRESSED PACKAGE SIZE: 11M
PACKAGE LOCATION: /var/log/mount/slackware64/a/glibc-solibs-2.15-x86_64-7.txz
PACKAGE DESCRIPTION:
glibc-solibs: glibc-solibs (shared GNU C libraries)
glibc-solibs:
glibc-solibs: This package contains the shared libraries, binaries, and support
glibc-solibs: files required to run most Linux applications linked with glibc.

PACKAGE NAME: glibc-2.15-x86_64-7
COMPRESSED PACKAGE SIZE: 12.0M
UNCOMPRESSED PACKAGE SIZE: 141M
PACKAGE LOCATION: /var/log/mount/slackware64/l/glibc-2.15-x86_64-7.txz
PACKAGE DESCRIPTION:
glibc: glibc (GNU C libraries)
glibc:
glibc: This package contains the GNU C libraries and header files. The GNU
glibc: C library was written originally by Roland McGrath, and is currently
glibc: maintained by Ulrich Drepper. Some parts of the library were
glibc: contributed or worked on by other people.
glibc:
glibc: You'll need this package to compile programs.

Вот простая иллюстрация к сказанному про установку удаление:

# 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/

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

"bormant⇓" написал:

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

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

"cdrw⇓" написал:

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