Похоже, что не получится у меня сделать как мне надо, ниасилю зависимости.

Следует кое-что разъяснить. У новичков зачастую о системе Slackware складывается превратное мнение. На самом деле хаб с документацией даёт разъяснение всех заданных в теме вопросов.

Я конструктивно останавлюсь на 2х главных вопросах без лишних деталей дабы добиться максимальной простоты.

Во-первых, документация гласит:

Before we continue, it is important to realize that the Slackware package manager does not perform any dependency checks. If you are new to Slackware, then performing a full installation (with the possible exception of the KDEI series) could prevent a lot of problems later on.

The official Slackware recommendation is “If you have the disk space, we encourage you to do a full installation for best results”.

we encourage you to do a full installation for best results

Таким образом вы можете сделать вывод - Slackware является монолитной системой и разработчик официально рекомендует проводить полную установку. Да, разработчик, знает, что что-то из того, что вы поставите будет для вас излишним, но это излишнее можно трактовать только как доп. занятое на диске место - оно не будет работать до тех пор, пока вы сами этого не захотите, при этом в дальнейшем это излишнее может вам понадобится в работе и вы запросто реализуете все свои задачи и цели, так как у вас под рукой монолит.

Идём дальше. Любителям минимализма такой совет (совет о полной установке системы) может не понравится. Они могут заявить: «Мне не нужен монолит, мне нужны куски».

Принимается. И эта задача решаема. Решается эта задача с помощью использования специальных Tagfiles. Суть такова:

The Slackware setup program handles installation of the software packages on your system. There are files that tell the setup program which packages must be installed, which ones are optional, and which ones are selected by default by the setup program.

A tagfile is in the first software series directory and is called tagfile. It lists the packages in that particular disk set and their status. The status can be:

Table 18-3. Tagfile Status Options

    Option 	Meaning
    ADD 	The package is required for proper system operation
    SKP 	The package will be automatically skipped
    REC 	The package is not required, but recommended
    OPT 	The package is optional

The format is simply:

package_name: status

One package per line. The original tagfiles for each software series are stored as tagfile.org. So if you mess up yours, you can restore the original one.

Many administrators prefer writing their own tagfiles and starting the installer and selecting “full”. The setup program will read the tagfiles and perform the installation according to their contents. If you use REC or OPT, a dialog box will be presented to the user asking whether or not they want a particular package. Therefore, it is recommended that you stick with ADD and SKP when writing tagfiles for automated installs.

Суть:

1. writing own tagfiles; 2. starting the installer and selecting “full”.

Т.е. вы пишите специальные тэгфайлы, отсеиваете те или иные пакеты, запускаете полную установку - установщик парсит тэгфайлы, устанавливает. За сим откланиваюсь.

ps Мой личный совет - обратие внимание на такие ОС, как NetBSD или CRUX. Перечитав ваши вопросы и запросы могу сделать вывод, что вам особенно подойдут NetBSD или CRUX. Если нужен GNU/Linux берите CRUX, если хочется чего-то нового и неожиданно прекрасного берите NetBSD. С самыми добрыми пожеланиями, ваш Аноним.

pss Поражает выдержка и образцовое поведение борманта - самый тактичный и приятный в общении человек на лоре. У меня бы на третьем топике о Slackware не выдержали нервы.

не получится у меня сделать как мне надо, ниасилю зависимости. Скорее всего после установки получу полурабочую систему

Возьмите
1) Salix (как Slackware stable) или
2) Slackel (как Slackware current) или
3) забейте на минимальную систему на первом этапе
либо
4) откажитесь от Slackware.

Отрезать от полной установки новичку проще: доступен анализ ситуации в рабочей системе, легче последствия ошибок (удалил - сломалось - вернул), проще фиксация результата. Поставил-изучаю куда лучше повторов «поставил-не работает»...

Почитал как люди на кофейной гуще гадают, какие же зависимости нужны при минимальной установке slackware

Это вы что-то не то читали, гадать нет никакого повода. Разные цели минимализма — разные наборы. Но поскольку «правильно поставленный вопрос всегда содержит более половины ответа», вы свою задачу пока сформулировать не в состоянии — нет опыта на те «более половины». Не поставите — не будет опыта.

плюсую анонимуса.
сам использую слаку и свои тагфайлы. получаю минимальную сборку.
несколько раз ошибался и неустанавливал нужные библиотеки, ldd /path_to_binary в помощь

1. Потому что в /etc, в отличии от шапок и зюзей, не было на..ано баш портянками
2. Потому что пэкеджи .tgz
3. Потому что был man -k pkg, что давало возможность понять, что делать дальше, имея опыт bsd и солярис

1. writing own tagfiles; 2. starting the installer and selecting “full”

Ремарка: «full» для случая, если заменили дистрибутивные своими, если положили рядом, то «custom» или «tagpath».

PS. С недавних пор есть менее болтливый «full» — «terse».

Не поставите — не будет опыта.

Мне до установки еще далеко, сначала нужно с пакетными менеджерами разобраться, с которыми в slackware так напутанно, как будто они специально не хотят чтоб их дистрибутив пользовали. И с elilo надо разобраться, потому как grub мне не нужен, я им и в раче не пользовался. Ну и с тэгфайлами найти общий язык, потому как в том виде, котором раздается slackware - мне не подходит от слова «совсем».

сначала нужно с пакетными менеджерами разобраться, с которыми в slackware так напутанно

Давайте разберемся.
Но поскольку мне непонятно, что же непонятно вам, попробуйте как-то сформулировать суть затруднений.

Базовый менеджер — pkgtools — состоит из набора сценариев, работающих локально с файлами пакетов (а removepkg еще и просто с именами): installpkg, removepkg, upgradepkg — поставить/удалить/заменить.
explodepkg распаковывает файл пакета в текущий каталог, послеустановочный сценарий doinst.sh не выполняется.
makepkg собирает в пакет поддерево от текущего каталога.
pkgtool позволяет в dialog-овом режиме поставить пакеты из каталога, удалить установленное, заново позвать установочные сценарии. Плюс еще кое-что, что обычно не требуется.
Страницы man у них есть, хоть и небольшие, но достаточно подробные.

Среди всех прочих наличных ПМ считается хорошим тоном для выполнения локальных операций с пакетами звать утилиты pkgtools, обеспечивающих локальную работу с файлами пакетов.

Для доставки обновлений/пакетов основного дерева с зеркал (сетевых или локальных) в качестве штатного менеджера служит slackpkg. Если добавить к нему сторонний плагин slackpkg+, станет работать с дополнительными репо тем же образом (почти).

Для тех же целей есть сторонний slapt-get — apt-подобный менеджер пакетов.

Для облегчения рутинных действий при сборке пакетов из готовых слакбилдов со slackbuilds.org есть sbopkg. Для сборки из исходников подключенных в slapt-get репо есть apt-подобный slapt-src.

Есть еще разный новодел на эту тему. Например spkg в Salix (осторожно, тот что в Salix — в чём-то был патчен не совсем совместимым образом, случайно обнаружилось, или тут, или на slackware.ru об этом писал).

с elilo надо разобраться

ну это самая простая часть. Бинарник elilo (elilo-*.efi), работающий из EFI, лежит на ESP, рядом лежит elilo.conf, в нем прописано, какой файл ядра с какими параметрами погрузить и запустить. Файл ядра и initrd лежат там же рядом (поскольку в efi гарантировано наличие поддержки ФС FAT, остальное по желанию и как правило отсутствует). Копируется туда это хозяйство при установке и вызовом eliloconfig (собственно его при установке и вызывают).
Почитать дополнительно можно в /usr/doc/elilo-*/ в установленной системе ;-)

с тэгфайлами найти общий язык

В этой теме выше уже и ссылки были и пояснения, думаю достаточно подробные. Но если остались вопросы — милости прошу.
Стоит ли с тегфайлами заниматься, отдельный вопрос. Однозначно да, если делаем свой дистрибутив или свой носитель с вариантами установки на базе Slackware. Возможно, да, если нужно ставить пачку машин обязательно с носителя (зачем? почему не раскатать образ?). Если ставить на одну машину — ну так себе занятие, если только — «лучше день потерять, потом за 5 минут долететь» как незыблемый и нерушимый принцип...
Но в установленной Slackware вам доступна ВСЯ информация по начинке, которой более чем достаточно для принятия грамотных и обоснованных решений (в том числе и что-то по-своему можно пересобрать). А ковыряние набора tagfile в сторонке в блокнотике... больше на гадание и сеансы спиритизма смахивает... Не в обиду будь сказано.

Так что, появятся вопросы, задавайте, желательно с контекстом, чтоб не вышло как в том анекдоте про «волны бились аборт корабля».

до установки еще далеко
с тэгфайлами найти общий язык

а с учетом сказанного в предыдущем сообщении, есть смысл накатить в ВМ, например, в тот же VirtualBox, обработать напильником пакетный состав до приемлемого состояния, затем отлить его в бронзе зафиксировать получившийся набор в тегфайлах.

Базовый менеджер — pkgtools

Значит его и буду пользовать

Для доставки обновлений/пакетов основного дерева с зеркал (сетевых или локальных) в качестве штатного менеджера служит slackpkg

Если я правильно понял, то pkgtools не в состоянии скачать пакет ?

Для облегчения рутинных действий при сборке пакетов из готовых слакбилдов со slackbuilds.org есть sbopkg

Это типо надстройка для pkgtools или самостоятельный менеджер ? Я имею ввиду как trizen для pacman`a.

Бинарник elilo (elilo-*.efi), работающий из EFI, лежит на ESP, рядом лежит elilo.conf, в нем прописано, какой файл ядра с какими параметрами погрузить и запустить. Файл ядра и initrd лежат там же рядом (поскольку в efi гарантировано наличие поддержки ФС FAT, остальное по желанию и как правило отсутствует). Копируется туда это хозяйство при установке и вызовом eliloconfig (собственно его при установке и вызывают).

Похоже на bootctl, которым я в раче пользовался, значит разберусь.

Стоит ли с тегфайлами заниматься, отдельный вопрос. Однозначно да, если делаем свой дистрибутив или свой носитель с вариантами установки на базе Slackware. Возможно, да, если нужно ставить пачку машин обязательно с носителя

Нет никакой пачки машин, есть 1 ноутбук дома и все. Есть задача избавиться от трояна systemd. Можете называть это как хотите:адваре, руткит, вирус - кому как угодно, так и называйте. А также избавиться от ненужных зависимостей, которые в раче гвоздями прибиты, вот поэтому выбор пал на slackware. Никаких веб разработок и прочей айтишной рутины. Вечером, после работы, посидеть 2-3 часа за ноутом, пересобрать пару свежих пакетов и в люлю. Вот и все.

О, хорошая мысль, подумаю как все лучше оформить.

Всё верно!

Да, и bormant, действительно, очень грамотный и доброжелательный человек.

А нужен ли вам elilo?

На моем домашнем ноуте прекрасно справляется простой и привычный lilo, проблем нет. Отключить в BIOS'е UEFI нельзя?

Отключить в BIOS'е UEFI нельзя?

Можно, но не отключу. Поэтому будет elilo.

О, хорошая мысль, подумаю как все лучше оформить.

Если про зафиксировать состав пакетов в набор tagfile, подскажу:
http://slackware.uk/people/alien/tools/tagfile_generator.sh

# Description:
#  Generate a set of Slackware tagfiles that reflects the state of packages
#  currently installed on your system.
#  You can use these tagfiles in a subsequent installation of Slackware to
#  install an identical set of packages.

Это Вам решать, Ваше право.

И, поскольку ТС спрашивал о причинах, по которым была выбрана Slackware - причина одна: все в системе просто, ничего лишнего, удобно использовать как десктоп (ИМХО).

Перепробовав Suse, Debian и его производные, Fedora и пр., всё равно вернулся на Slackware, сейчас current64, всё хорошо, радуюсь.

pkgtools не в состоянии скачать пакет ?

Правильно. Все утилиты из состава pkgtools работают на смонтированной ФС с файлом-пакетом (кроме removepkg, ему очевидно достаточно имени для удаления пакета ;-) ) и файлами, все они сценарии bash (можно посмотреть, что именно делают).

pkgtools — это нижний уровень — установить/удалить/заменить, собрать пакет/разобрать пакет. Все прочие ПМ эти операции проделывают при помощи утилит из pkgtools. (На всякий случай во избежание возможной путаницы: pkgtool — это одна из утилит pkgtools).
Взять slackpkg — он синхронизирует метаданные зеркала, строит списки пакетов, загружает файлы пакетов, чистит кеш загруженного, но для установки/удаления/замены приехавшего на ФС пакета зовет кого-то из pkgtools. Каждый занимается своим делом.

sbopkg

Это типо надстройка для pkgtools или самостоятельный менеджер ? Я имею ввиду как trizen для pacman`a

Пробежал наискось описание, вроде немного похож.
Сфера ответственности sbopkg — забрать со slackbuilds.org запрошенные слакбилды, загрузить исходники, построить пакеты, поставить их, проверить актуальность и т.п.
Без параметров запускается в dialog-овом режиме, предоставляет почти полный набор возможностей: синхронизировать дерево слакбилдов, поискать по ему, почитать описание, поправить слакбилд, набрать очередь на сборку, запустить сборку, построить пакеты, поставить их при помощи pkgtools, почистить кеши исходников и слакбилдов и т.п.
Запущенный с ключами делает что задали.

Позволяет вместо проводимого руками:
1) скачать слакбилд,
2) распаковать,
3) скачать исходники,
4) почитать README,
5) если нужно что-то доставить — проделать пункты (1)-(7) по количеству этого чего-то
6) позвать bash *Build
7) позdать upgradepkg --install-new /tmp/чего-собрали.t?z

ограничиться
# sqg -p чего-надо
# sbopkg -Ri чего-надо.sqf

Тоже сценарий bash, тоже можно почитать.

Более/менее понятно, думаю, что разберусь. Немного практики и совсем хорошо будет.

Какое ядро предпочтительнее для домашнего пользователя: huge или generic ? И чтоб по 2 раза не ходить, сразу спрошу. В раче при установке gcc в зависимостях идет gcc-libs. Будет ли достаточно в slackware ограничиться только gcc ?

Какое ядро предпочтительнее для домашнего пользователя: huge или generic ?

huge — установочное, generic — рабочее.
1) Оба собраны на примерно одном конфиге, чтобы иметь возможность не дублировать модули для каждого из них.
2) В huge добавлены драйверы основных контроллеров и файловых систем, чтобы иметь возможность использовать его без initrd в подавляющем большинстве случаев, но при этом не иметь конфликтов с как можно большим количеством прочих модулей. Это же ядро используется в установочном окружении.
3) В generic нет ничего из п.(2) ==> без initrd, содержащего все необходимое для монтирования корневой ФС, его использовать невозможно. Отсюда неприятное следствие: если забыть перестроить initrd после обновления ядра, то отвалится загрузка. Придется погрузиться с установочного носителя и поправить — неудобно. Либо заранее заготовить 2 варианта загрузки — и с generic, и с huge. Для стабильных выпусков невелика проблема — ядра приходят весьма редко, но в current ядра приходят часто: либо игнорировать их обновление, либо не забывать об обновлении initrd.
3.1) для системы с EFI ситуация усугубляется дополнительной необходимостью копировать и ядро, и initrd на ESP (которая на FAT и не поддерживает симлинки).
4) Категоричного запрета на использование huge в качестве основного ядра нет, например, Salix поступает именно так.
5) В документации generic недвусмысленно названо ядром для повседневного использования.

В раче при установке gcc в зависимостях идет gcc-libs. Будет ли достаточно в slackware ограничиться только gcc ?

Основные .so из состава Arch-евого gcc-libs продублированы в пакете aaa_elflibs. Если их недостаточно, тогда необходимое принесет соответствующий gcc-*.

Отсюда неприятное следствие: если забыть перестроить initrd после обновления ядра, то отвалится загрузка. Придется погрузиться с установочного носителя и поправить — неудобно.

Если даже и забуду, то ничего страшного, починю. Меня вполне устраивает, что вместо меня в этот процесс ничто вмешиваться не будет. Но я не забуду.

Основные .so из состава Arch-евого gcc-libs продублированы в пакете aaa_elflibs

Это мне подходит, и даже очень.

Если даже и забуду, то ничего страшного, починю. Меня вполне устраивает, что вместо меня в этот процесс ничто вмешиваться не будет. Но я не забуду.

Я выше писал, про возможность копирование ядра и initrd на ESP вызовом eliloconfig. Для current с его частыми обновлениями ядра этот способ НЕ является предпочтительным — он более комплексный, чем нужно: переустанавливает elilo на ESP, переписывает elilo.conf, копирует /boot/vmlinuz, boot/initrd.gz, а также при помощи efibootmgr стирает старую загрузочную строчку в nvram и создает новую.

В этом месте самое время вспомнить про устройства, окирпичивавшиеся от относительно небольшого количества перезаписей в nvram.

Поэтому для обновления ядер на ESP есть смысл написать тривиальный сценарий из нескольких строчек на bash, который вызывать, если были обновлены ядра, что-то вроде:

#!/bin/bash

mkinitrd -c -F
cp \
  /boot/vmlinuz-generic \
  /boot/vmlinuz-huge \
  /boot/initrd.gz \
  /boot/efi/EFI/Slackware/

KERNEL_VERSION=$(readlink /boot/vmlinuz | cut -d- -f3)
MODULE_LIST=ext4  # ФС корня

/etc/mkinitrd.conf ... поправить в нем как минимум строки:

KERNEL_VERSION=$(readlink /boot/vmlinuz | cut -d- -f3)
MODULE_LIST=crc32c-intel:ext4  # ФС корня

Под VirtualBox этого было достаточно, mbcache и jbd2 приезжали сами, но без явного указания crc32c-intel загрузка обрывалась внутри initrd.
Насчет списка модулей на конкретном железе также не лишним будет глянуть на выхлоп:

# /usr/share/mkinitrd/mkinitrd_command_generator.sh