Установка программ в Slackware

[Bizdelnick]

kernel-headers, которые при каждой конфигурации ядра будут индивидуальны

Они индивидуальны для каждой версии, но не для каждой сборки.

[bormant]

Как обычно вопрос в соотношении цена/качество -- сколько потратить усилий и какой результат буден получен, не только сейчас, но и если что-то поменяется.
Если есть гарантия, что для стокового ядра пакет собран без закладок и без лишних зависимостей, то отчего бы и нет, если только... Если любите пособирать свои ядра, то в какой-то момент пакет может уже не подойти, а исходники - вот они, под руками, пересобрал, поставил, и снова в бой.

Да, знаю, есть софт, пересборка которого занимает очень много ресурсов и не на каждой машинке может быть проведена. Хм, я уже говорил про компромисс?

В общем всё по классику: поднимем бокалы, содвинем их разом, да здравствуют музы, да здравствует разум! Пренебрежение последним скорее всего лишит и первых трёх :D

[drBatty]

Теперь, когда вопросы по работе с репозиторием исчерпаны, поговорим о доп. пакетах. Что всё-таки лучше: найти готовый пакет и установить его или найти слакбилд?

вопрос не имеет смысла. Часто выбора просто нет.

Вот нужет проприетарный драйвер broadcom-sta, нашёл готовый пакет тут и слакбилд тут.

готовый будет работать без глюков только в этой версии дистрибутива. В другой версии он будет глючить, или вообще не будет работать. Потому надо собирать слакобилд, либо держать эту вашу 13.37, которая давно устарела.

Как обычно вопрос в соотношении цена/качество -- сколько потратить усилий и какой результат буден получен, не только сейчас, но и если что-то поменяется.

выбора часто нет. Например невозможно собрать гуглохром (только хромиум), т.к. нет исходников. Также невозможно скачать пакет стабильной версии f2fs, потому-что таковой в природе на сегодня не существует, и можно только стянуть снапшот в git'овом репозитории.

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

[sunny1983]

drBatty, спасибо это я понял, что в каждом отдельном случае решение индивидуальное. Вопросы "не имеющие смысла" я задаю, потому что пока особо не практиковал, только теоретезирую.
Как правильно устанавливать программы из слакбилдов? Слакбилд это просто shell-скрипт, то есть его нужно просто запустить из-по рута? При этом скачаются исходники, патчи, всё пропатчится, запустится мейкфайл, компиляция, установка и в конце создание файла в базе пакетов/var/log/package, чтобы при желании можно было всё удалить? А если возникнут ошибки при компиляции из-за неверных зависимостей или ещё чего-нибудь явместо рабочей программы получу кучу мусора в системе, как его тогда вычищать?

[drBatty]

Как правильно устанавливать программы из слакбилдов?

Ъметод: прочитать СНАЧАЛА README. Это убережёт вас от 99% проблем. Можно не читать, но тогда файлопомойка будет начинаться с корня.

Слакбилд это просто shell-скрипт, то есть его нужно просто запустить из-по рута?

вопрос не имеет смысла © (:
часто -- да. Не забудьте потом почистить $TMP или что там у вас? (/tmp обычно. У меня он сам чистится)
главное -- голову не отключать, остальное уже мелочь.

При этом скачаются исходники, патчи, всё пропатчится, запустится мейкфайл, компиляция, установка и в конце создание файла в базе пакетов/var/log/package, чтобы при желании можно было всё удалить?

вряд-ли. Часто надо всё ручками качать, а потом в /tmp будет куча мусора, среди которого будет и пакет. Который опять ручками надо ставить. Sbopkg автоматизирует этот процесс более-менее. Если конечно вы голову не отключили.

А если возникнут ошибки при компиляции из-за неверных зависимостей или ещё чего-нибудь явместо рабочей программы получу кучу мусора в системе, как его тогда вычищать?

дык он и не поставится. Даже если ошибок не будет. Даже с sbopkg.

А если поставите (installpkg), то удаляйте также(removepkg).

Hint: автодополнение не забудьте к bash'у поставить. Это избавит вас от очепяток.

[bormant]

Слакбилд это просто shell-скрипт, то есть его нужно просто запустить из-по рута?

Для сборки пакета -- да, но зависит от слакбилда. Например, сценарии .SlackBuild со slackbuilds.org сами ничего не загружают. Рядом есть файлик .info, в котором описано, откуда что скачать. Такова политика сайта. Стоковые слакбилды тоже ничего не загружают.
В других местах слакбилды могут писать по-другому. Например, некоторые слакбилды от AlienBOB-а имеют строчки с загрузкой исходников. Слакбилды со slacky.eu загружают исходники самостоятельно, типичный пример:

Код: Выделить всё

PKGNAME=libdvdcss
VERSION=${VERSION:-1.2.13}

SOURCE="http://download.videolan.org/pub/libdvdcss/$VERSION/$PKGNAME-$VERSION.tar.bz2"

# Download sorce tarball if still not present
if [ ! -e $CWD/$PKGNAME-$VERSION.tar.bz2 ]; then
wget -c $SOURCE
fi

При этом скачаются исходники, патчи, всё пропатчится, запустится мейкфайл, компиляция, установка и в конце создание файла в базе пакетов/var/log/package, чтобы при желании можно было всё удалить?

Обычно, до изготовления пакета. Иногда с его (пакета) установкой. Но не с "make install" напрямую. Обычно выполняется "make DESTDIR=/tmp/package-xxx install", содержимое DESTDIR дополнительно причёсывается при необходимости, затем из него делается пакет. См. http://www.gnu.org/prep/standards/html_node/DESTDIR.html

А если возникнут ошибки при компиляции из-за неверных зависимостей или ещё чего-нибудь я вместо рабочей программы получу кучу мусора в системе, как его тогда вычищать?

Если возникнут проблемы с компиляцией, до установки в DESTDIR и сборки пакета дело вообще не дойдёт. По крайней мере, хорошим тоном является делать "set -e" или проверять критичное по "... || exit 1".

[bormant]

Процесс сборки вручную со slackbuilds.org может выглядеть как-то так (на примере ncdu):

Код: Выделить всё

# mkdir ~/bld; cd ~/bld
# wget http://slackbuilds.org/slackbuilds/14.1/system/ncdu.tar.gz
# tar xf ncdu.tar.gz
# cd ncdu
# less README
# source *info
# echo $REQUIRES
# wget $DOWNLOAD
# ./*Build
# upgradepkg --install-new /tmp/ncdu-$VERSION-*t?z

То же самое при помощи sbopkg:

Код: Выделить всё

# sbopkg -Ri ncdu

[sunny1983]

Каким способом можно в Slackware установить зараз группу пакетов, например группы kde и kdei одновременно?

[drBatty]

Каким способом можно в Slackware установить зараз группу пакетов, например группы kde и kdei одновременно?

Shell

# cd slackware/kde # installpkg *.t?z

на счёт kdei я вас не понял, вам нужны ВСЕ локализации?

ещё вариант

Shell

# sh install-packages

[sunny1983]

installpkg умеет распознавать символы подстановки. Как просто всё оказалось.

[drBatty]

installpkg умеет распознавать символы подстановки. Как просто всё оказалось.

не умеет.

Это bash умеет. Если не верите, наберите

Код: Выделить всё

echo *.t?z

И да, используйте эту возможность аккуратно, ибо можно всё загубить, если не вовремя установить glibc например.

[sunny1983]

А как в Slackware добавить поддержку 32-битных программ в 64-битную систему?

[bormant]

http://docs.slackware.com/ru:slackware:multilib

Обратите внимание на дополнение в английской версии http://docs.slackware.com/slackware:multilib

There is also slackpkg+, written by Matteo Rossini (nicknamed zerouno) with contributions from (among others) Sėbastien Ballet. This is a plugin for Slackware's own slackpkg which adds the capability for installing packages from external (3rd-party) unofficial Slackware repositories. It has good support for adding multilib to your 64-bit Slackware and keeping it up to date.

С учётом этого дополнения (про slackpkg+) установка 32-битного слоя превращается в

Код: Выделить всё

# slackpkg install multilib

ps. Синхронизировал русский перевод с английским вариантом, есть существенные изменения к предыдущему тексту, прошу обратить внимание: http://docs.slackware.com/ru:slackware:mul...type=sidebyside

[sunny1983]

Сейчас снова вернулся к минимальной установке Slackware. Если делаю full-установку, то всё работает нормально, хотя и присутствует куча лишних программ в системе. Если же делаю минимальную установку - приходится мучиться с зависимостями. Это хорошо если программа в консоли пишет имя необходимого файла, который отсутствует, а если что-то невразумительное пишет? Собственно вопрос, для Skackware еще не придумали средство автоматического подтягивания зависимостей, может скрипт какой?

[bormant]

sunny1983
а вы сделайте полную установку, удалите кучу лишних программ, вы же знаете, что именно лишнее, а если что-то сломается из-за удаленного по ошибке, вернете обратно, вы же помните, что только что удаляли.
Достигнутый результат можно зафиксировать для использования в будущем при помощи slackpkg template или создав набор tagfile-ов.

Минимальные наборы можно подсмотреть, например, в Salix.

Там же и зависимости оригинальной Slackware посмотреть на одном из зеркал, http://download.salixos.org/i486/slackware-14.1/deps

Можете взять PACKAGES.TXT на зеркале Salix, например, http://download.salixos.org/i486/slackware-14.1/, в нем прописаны зависимости, заменить им одноименный файл локального зеркала пакетов, либо дописать для каждого пакета зеркало строкой, например:

Код: Выделить всё

PACKAGE MIRROR:  http://slackware.osuosl.org/slackware-14.1/

и использовать каталог в качестве репозитория. Менеджером пакетов использовать slapt-get.

Возможен вариант перехода на репозитории Salix либо установка Salix с нуля. Пожалуй, самые близкие варианты для "Slackware с поддержкой зависимостей".

[yars]

Если же неохота Salix ставить, то можно пользоваться sbbdep, полезная вещь.

[bormant]

yars
sbbdep -- он Salix-у ортогонален, его и тут, и там можно использовать с одинаковым успехом.

[sunny1983]

Интересно, вот почему Slackware держится в top10 на distrowatch.com, а её форки, те же Salix и Zenwalk такой популярностью не пользуются. Мне нужен дистрибутив, репозиторий которого регулярно поддерживается и будет поддерживаться ещё как минимум лет пять, по которому я смогу найти поддержку на тематических форумах и который был бы удобен в использовании одинаково как на десктопе, так и на ноутбуке, так и на сервере.

[bormant]

sunny1983
полагаю, что выполнение обещаний все еще в цене. Еще есть те, кого привлекают простота устройства дистрибутива, предсказуемость инструментария, понятный курс.

Если кто-то понял, что ему на самом деле был нужен Debian/Ubuntu или RedHat/CentOS или LFS, то ушел он точно не на Zenwalk/Salix. В общем-то предсказуемая статистика.

[alv]

Интересно, вот почему Slkackware держится в top10 на distrowatch.com, а её форки, те же Salix и Zenwalk такой популярностью не пользуются.

А мне интересно, когда Вы последний раз видели Slackware в top10?
Боюсь, что в те годы, когда ещё Distrowatch'а не было.
Сейчас Slackware и Salix стабильно ноздря в ноздрю идут между 30-й и 40-й позицией.
А Zenwalk, когда Жан-Филипп развивал его очень активно, в конце нулевых то есть, столь же стабильно был примерно вдвое выше Slackware.
Про то, что Distrowatch в принципе показатель не числа пользователей, а количества любопытствующих, я уж и не говорю.

Мне нужен дистрибутив, репозиторий которого регулярно поддерживается и будет поддерживаться ещё как минимум лет пять.

Репозиторий Zenwalk'а поддерживается более 10 лет - и помирать не собирается.
Влахавас с Дзевасом тоже.

[sunny1983]

http://distrowatch.com/dwres.php?resource=major

[alv]

http://distrowatch.com/dwres.php?resource=major

Это не тот топ, а некий мифический.
Тот - в правой колонке

[Hephaestus]

С учётом этого дополнения (про slackpkg+) установка 32-битного слоя превращается в
# slackpkg install multilib

Я себе запилил мультилиб, но не этим способом, а как в доке описано.
А потом и slackpkg+ поставил.
Так вот в доке говорилось, что нужно заморозить пакеты, *alien и *comp32, дабы они случайно не обновились обратно до 64бит.
А при использовании # slackpkg install multilib эта рекомендация остаётся в силе?

И ещё: я не совсем понял, какие репы в slackpkg+ подключать. Некоторые там уже подключены, другие - нет, а вот какие надо - не знаю.
У меня-то основные это - официальные репы да slackbuilds.org. Если ещё чего-то надо - делаю слакбилды-самосборы, складываю в локальную репу. sbopkg её умеет.

[bormant]

нужно заморозить пакеты, *alien и *comp32, дабы они случайно не обновились обратно до 64бит.
эта рекомендация остаётся в силе?

И да, и нет.
Да, потому как обновления их обратно до 64-бит допускать по-прежнему не следует.
Нет, потому что достигается сей эффект несколько иначе, а именно выставлением хранилищу мультилиба более высокого приоритета.

Желательно почитать /usr/doc/slackpkg+-*/README
А также приметить наличие /usr/doc/slackpkg+-*/setupmultilib.sh

Подготовительная стадия перед вызовом slackpkg install multilib описана в документации и состоит в:

а) вызове # /usr/doc/slackpkg+-*/setupmultilib.sh
либо проделывании тех же манипуляций вручную в /etc/slackpkg/slackpkgplus.conf:

- раскомментировать подходящее хранилище multilib:
MIRRORPLUS['multilib']=...

- добавления приоритета хранилищу multilib:
PKGS_PRIORITY=( multilib:.* )

- добавления multilib в список REPOPLUS

б) далее стандартно для первой установки:
# slackpkg update gpg
# slackpkg update
# slackpkg upgrade-all
# slackpkg install multilib

в) последующее обновление:
# slackpkg update
# slackpkg upgrade-all

ps. Хм, где-то я это уже переводил... Точно, переводил: http://www.slackware.ru/forum/viewtopic.php?f=9&t=1297

[sunny1983]

Сам недавно ставил мультилиб рекомендованым способом:

Код: Выделить всё

$ mkdir multilib
$ cd multilib
$ lftp -c "open http://www.slackware.com/~alien/multilib/; mirror -c -e 14.1"
$ sudo upgradepkg --reinstall --install-new 14.1/*.t?z
$ sudo upgradepkg --install-new 14.1/slackware64-compat32/*-compat32/*.t?z
$ sudo chmod 755 /etc/profile.d/32dev.sh
$ sudo reboot

32-битные программы Adode Reader и Wine работают нормально.

[sunny1983]

Тут выше упомянался slackpkg+. Это сколько ж нового узнаёшь. В качестве средств управления пакетами в slackware существуют: installpkg/removepkg/upgradepkg, pkgtool, slackpkg, slapt-get, sbopkg, slaptget+. Какими из них вы реально пользуетесь, а какие не нужны?

Сейчас Slackware и Salix стабильно ноздря в ноздрю идут между 30-й и 40-й позицией.
А Zenwalk, когда Жан-Филипп развивал его очень активно, в конце нулевых то есть, столь же стабильно был примерно вдвое выше Slackware.
Про то, что Distrowatch в принципе показатель не числа пользователей, а количества любопытствующих, я уж и не говорю.
Репозиторий Zenwalk'а поддерживается более 10 лет - и помирать не собирается.
Влахавас с Дзевасом тоже.

Так чем всё-таки лучше пользоваться: оригинальным Slackware или одним из форков? Что лучше поддерживается?
И как профессионалы советуют делать установку: всегда full или всё же можно по минимуму. Я тут эксперементировал с минимальной установкой, ставлю 66 пакетов, а дальнейшую доустановку веду по мере надобности, даже взялся писать статью для Хабра по минимальной установке, но правда ладно всё только если делается установка для сервера, работающего без иксов. Если же нужен графический интерфейс - то это кошмар, в KDE так и не заставил работать Nepomuk.

[yars]

Код: Выделить всё

sudo chmod 755 /etc/profile.d/32dev.sh

Это опционально, и нужно если вы компилируете 32-разрядные приложения в 64-разрядном окружении постоянно. Если же вам потребуется собрать 64-разрядную программу, то вам придется проделывать действия, обратные действиям скрипта, а именно сбросить в значения по умолчанию:

Код: Выделить всё

QT4DIR=/usr/lib64/qt
PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig:/usr/local/lib64/pkgconfig
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/qt/bin

и сделать unset LD_LIBRARY_PATH CC CXX FC F77, а также проследить, что переменная $ARCH указывает на верную архитектуру (x86_64).

[alv]

Так чем всё-таки лучше пользоваться: оригинальным Slackware или одним из форков?

Это очень разные вещи. Zenwalk - действительно форк, уже не очень совместимый с оригиналом.
А Salix и Slackel можно воспринимать в том числе и просто как инсталлятор для обычной Slackware, stable и current соответственно.
Которые и избавляют как раз от самого страшного в этом дистрибутиве: ставить full и поиметь кучу ненужного софта, или затратить кучу времени на выборочную установку без гарантии, что ничего не забыл.
А здесь - ставится вариант BASIC (то есть с Иксами и минимальным десктопом).
Дальше есть выбор: или жить в Salix/Slackel (они совсем не страшные), или лёгким движением slackpkg (ещё без плюса!) превратить их в оригинал.
Вот здесь типа описано: http://alv.me/?page_id=1627#salix
PS А в терминах автора известной поэмы это не описывается. Потому что и то, и другое, и третье не всегда однозначно хорошо, и не обязательно плохо.

[bormant]

Какими из них вы реально пользуетесь, а какие не нужны?

Так уж получилось, что перечисленные инструменты имеют определенное назначение и иерархию. В двух словах так:

Пакет pkgtools содержит базовый пакетный менеджер Slackware: утилиты installpkg, removepkg, upgradepkg, makepkg, explodepkg и pkgtool.
Назначение каждой понятно из названия, подробности в руководстве man (если поставить пакет от SLINT (см. на slint.fr), то и на русском языке).
pkgtool дает к некоторым из них dialog-овый интерфейс (от названия программы dialog) и, для многих может быть сюрпризом, откликается на некоторые параметры комстроки :-). Помимо установки/удаления пакетов поддерживает а) просмотр списка файлов, установленных из пакета packagename (по сути less /var/log/packages/packagename), б) повторное выполнение отдельных установочных сценариев (тех, что ставятся в /var/log/setup/), среди них настройка времени, lilo, мыши, сети, сервисов, шрифта консоли, и т.п. (при установке системы вы видели именно их работу).
Все они работают локально с локальными файлами пакетов, removepkg умеет удалять по имени пакета (полному или родовому).
Именно они обеспечивают ведение лоальной базы установленных, удаленных, обновленных пакетов (/var/log/{packages,scripts,removed_packages,removed_scripts}).
Все прочие инструменты для установки/удаления пакета используют средства pkgtools.

slackpkg помимо локальных файлов умеет работать с сетевым репозиторием (одним), загружать из него пакеты, синхронизировать состояние системы, выполнять апгрейд на новую версию системы.

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

slapt-get появился как аналог apt для Slackware, в отличие от slackpkg написанный на Си, а не на bash. Умеет автоматическое разрешение зависимостей, при наличии информации о зависимостях в репозитории (а именно в PACKAGES.TXT).
slapt-src появился по аналогии с apt-src для автоматизации сборки пакетов из исходников.
Есть графическая морда Gslapt.
Вся эта троица живет на http://software.jaos.org/

Не секрет, что базовый набор софта Slackware является хотя и вполне самодостаточным для обычного десктопа, но действительно базовым, Патрик весьма консервативен в добавлении стороннего софта. В какой-то момент хочется чего-то, отсутствующего в дистрибутиве. Силами таких желающих создавались разные репозитории по модели официального, которые включали помимо собранных пакетов и сценарии сборки -- слакбилды. Ставить бинарные пакеты неизвестно откуда, собранные неизвестно кем неизвестно из чего и неизвестно как -- не самая хорошая, да что там, отвратительная, идея. Так появился, заматерел и набрал популярность slackbuilds.org -- сайт только слакбилдов, содержащих ссылки на необходимое для сборки.
Потом кому-то, чье имя указано на http://sbopkg.org/ и в одноименном пакете, надоело повторять одни и те же операции по сборке из слакбилдов, и на свет появился sbopkg, заточенный на работу с сайтом slackbuilds.org. Задачи: сборка пакетов из исходников с выполнением всех сопутствующих шагов: загрузка слакбилда, исходников, проверка сумм/подписей, запуск слакбилда, установка собранного, проверка обновлений.

Но и эта работа требовала составлять очередь сборки руками. Для генерации сборочной очереди со всеми зависимостями был написан sqg -- sbopkg queuefile generator.

PS. Утилита sbbdep, анализирующая зависимости установленных пакетов, хотя и не относится непосредственно к установке, но может весьма полезна, упрощая анализ зависимостей бинарных файлов.

[sunny1983]

bormant, slapt-get и slapt-src кажется являются официальными инструментами управления пакетами дистрибутива Salix.
А slackpkg+ тоже в состав какого-то из форков Slackware входит или это сама по себе программа?

Кстати слакбилды нормально собирают только будучи запущеными из-по рута, как я заметил.