Форум Slackware Linux

Подумываю перейти с дебиана на слаку. В связи с этим несколько вопросов.

1) как узнать список файлов пакета? (аналог dpkg -L package_name)
2) как узнать какому пакету принадлежит файл? (аналог dpkg -S file_name)
3) как установить всё необходимое для сборки пакета из исходников? (аналог apt build-dep package_name)
4) если я хочу в стабильной ветке обновить пакет gtk+3 на версию из current-ветки, то как это правильнее всего сделать?

1) если установленного пакета, то
cat /var/log/packages/package-...
если файла пакета
tar tf package-...
2) если установленного пакета, то
slackpkg file-search /path/file
или
grep -r path/file /var/log/packages/
Если того, который не установлен, то поиском по манифесту из хранилища. Манифест можно загрузить отдельно, либо использовать тот, что загружает slackpkg в /var/lib/slackpkg/.
3) почитать README в исходниках.
На самом деле, если исходники из дистрибутивного дерева, то все необходимое есть в дистрибутиве, и, соответственно, в полной установке.
Если речь о сборке из SBo, то зависимости явно указаны, в том числе сборочные.
4) правильно такого (брать бинарный пакет) не делать, по крайней мере тогда, когда current ушел по библиотекам от стабильной версии.
Правильно было бы взять слакбилд и собрать новую версию. Правда не всегда это бывает возможно малой кровью. Особенности сборки можно подсмотреть в слакбилде из current.
Если говорить конкретно про 14.2 и будущую 15.0, то в последней отказались от *.la, поэтому напрямую оттуда тянуть слакбилды нельзя, нужно будет эту особенность скорректировать.

PS. Добро пожаловать.
И, главное, не стесняйтесь спрашивать.

_________________
irc://freenode.net/##slackware-ru

С аналогами dpkg -L и dpkg -S понятно. Благодарю.

Про сборку давайте на конкретном примере разберём.
Мне хочется установить пакет gtk+3 из current-ветки в стабильную.
То есть мне для это потребуется:
1) найти пакет с исходниками на сайте (вот он https://mirrors.slackware.com/slackware ... e/l/gtk+3/ )
2) скачать исходники пакета через браузер
3) почитать readme, чтобы определить зависимые пакеты для сборки
4) проделать пункты 1-3 для каждого зависимого пакета
5) в каждом слакбилде закомментировать строку rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la (чтобы были пригодны для стабильной ветки)
6) методом тыка определить порядок, в котором собирать зависимые пакеты
7) установить собранные *.txz через upgradepkg

Всё правильно?

Могу спросить, зачем?

1) да, тут все просто, зеркало/slackware64-current/source/gtk+3
2) зачем же через браузер, есть rsync, есть lftp, в конце-концов даже в mc можно
cd /ftp://slackware.uk/slackware/slackware64-current/source/l
Crl+S gtk+3 F5 Enter
3) странно было бы собирать что-либо, не зная, что об этом процессе думают разработчики собираемого.
В файле INSTALL от gtk+-3.22.30 сказано:

4) да
5) да
6) если документация зело крива, то придется методом тыка, куда ж деваться
7) да

Добавить список замененных дистрибутивных пакетов в черный список slackpkg
в файл /etc/slackpkg/blacklist руками
или "slackpkg blacklist маска-пакета-1 маска-пакета-2 ..."
иначе при slackpkg upgrade-all он предложит вернуть дистрибутивные пакеты на место.

Хочу сразу предупредить -- то, чем вы собираетесь заняться, отношения к использованию дистрибутива Slackware имеет мало, скорее это создание собственной системы на базе Slackware, пусть и не тиражируемой. Одно дело, когда вы дополняете установку тем, чего нет в конкретной версии. Совсем другое дело, когда вы меняете часть дистрибутива (то есть берете эту часть под свой собственный контроль и больше не получаете в этой части обновлений безопасности). Тем более, когда заменяются базовые пакеты, от которых много что зависит (и не факт, что такая замена полностью совместима с остальными частями).
В ситуации, когда набор версий ПО в конкретном релизе вот совсем-совсем не удовлетворяет требованиям, есть смысл посмотреть или в сторону current (естественно, с определенными предосторожностями. Тем не менее, в ней эта часть пути была ранее уже была проделана разработчиком дистрибутива), или в сторону другого дистрибутива. Либо сказать "я достаточно смел и квалифицирован, чтобы пилить своего франкенштейна на свой страх и риск".
Предупредил ^)

_________________
irc://freenode.net/##slackware-ru

Чтобы нужные мне gtk3-темы заработали, так как они требуют минимум 3.20 версии gtk3, а в стабильной ветке 3.18. Мне подумалось, что проще библиотеку gtk3 обновить, чем переписывать темы. Хотя сейчас уже нашлась под 3.18 нормальная тема, так что можно обойтись без обновления библиотеки. Но тем не менее, хочется знать порядок действий, если действительно понадобится обновить какой-либо пакет из current-ветки.


В дебиане предлагает обновить только при более высоком номере версии. Ок, будем знать.

Ещё. Допустим, через upgradepkg обновил пакет freetype.

slackpkg search freetype среди прочего выдаёт
freetype-2.9.1-x86_64-2 --> freetype-2.6.3-x86_64-2_slack14.2

это доступна информация об изменении версии только для последнего обновления, или при последующих upgradepkg вся история обновлений где-то сохраняется?



Если в стабильной слишком много пакетов из current накопится, то так и сделаю.

Про версии: тут два момента.
1. Про slackpkg. Он просто смотрит в метаданные хранилища. Для стабильных выпусков там либо только одна версия пакета в основном поддереве /slackware*/, либо две — если выпускалось обновление безопасности (или несколько обновлений, на зеркале остается только последнее) — и в /patches/packages/, именно туда приходят обновления. С current чуть иначе: поскольку это разрабатываемая версия, все изменения идут сразуи в основное поддерево /slackware*/.
2. Про историю обновлений. Она пишется в /var/log/removed_packages/ и /var/log/removed_scripts/ (туда при обновлении копируются файлы из /var/log/{packages,scripts}. Однако slackpkg, да и кто-либо еще из стандартных утилит, ею не пользуется.

Дерганье бинарных пакетов из current до добра не доведет, особенно сейчас, когда ветки разошлись очень сильно. Как минимум возьмите sbbdep, хотя бы сможете предварительно оценить масштаб потенциальной трагедии (например, sbbdep --whoneeds /var/log/packages/freetype-*)

_________________
irc://freenode.net/##slackware-ru

zizzu, вам знаком термин API? он меняется от версии к версии и если вы "обновляете" одну библиотеку вам нужно будет соблюсти совместимость с API всех зависимых от нее приложений. Отсутствие совместимости будет выливаться или в ошибки при сборке пакета, или в сегфолт ранее исправно работавших приложений.

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

С историей обновлений понятно. sbbdep — полезная штука.

Еще вопросы.

1) в /etc/slackpkg/slackpkgplus.conf включил зеркала slackpkgplus restricted alienbob slacky slackonly.
Какие ещё порекомендуете нормальные зеркала с готовыми пакетами или слакбилдами?

2) заметил, что содержимое /tmp после перезагрузки системы автоматически не очищается. Там, например, исходники и пакеты, которые собирались из слакбилдов. На какой случай они там хранятся, если при пересборке всё равно заново скачиваются?

3) сборку из слакбилдов принято делать от рута или от пользователя?

1) Со slacky осторожнее, там любят собирать с весьма развесистыми зависимостями... По той же причине с ним предпочтительнее slapt-get. Ну и следить, чтобы наборы пакетов по возможности с чужими не пересекались. Тут нужно оговориться, что этому моему опыту уже много лет, могло что-то и поменяться за это время, но осадочек остался ;)
Список прочих актуальных есть в slackpkgplus.conf.
Дополнительные хранилища определяются потребным софтом. Поисковик есть на родине slackpkg+ — http://slakfinder.org/.

Обратите внимание на sbopkg — удобный инструмент для slackbuilds.org, документация в /usr/doc/sbopkg-*/. Но это про сборку...

2) Можно чистить руками, можно дописать команду в /etc/rc.d/rc.local, хозяин-барин. Отдано на откуп администратору. У тех, кто в /tmp смонтировал tmpfs, поправив /etc/fstab, все само пропадает при перезагрузке.
Насчет скачивания при пересборке — по-разному бывает, например, sbopkg качает в /var/lib/sbopkg/, /var/cache/sbopkg/.

3) от рута, причем из полноценного рутового окружения ("su -" (он же "su- l", он же "su -l root"), просто "su" недостаточно). На самом деле действительно чувствительных к этому пакетов не так уж и много, но они есть. На оф.форуме на LQ были хорошие темы про fakeroot для сборки от пользователя, и про overlayfs для контроля/отладки установочной части слакбилдов. Но официальный метод прежний — от рута из рутового окружения.

_________________
irc://freenode.net/##slackware-ru

Ну вот и весь нужный софт в слаке поставлен и заработал. Благодарю за разъяснения.

Bormant, а можно подробнее разъяснить пункт второй?

Давайте сделаем так: почитаете
http://docs.slackware.com/howtos:genera ... your_space
а если останутся вопросы -- обсудим.
Ок?

_________________
irc://freenode.net/##slackware-ru

Благодарю за полезную ссылку. Каталог /tmp теперь чистится автоматически (чего мне и не хватало в Slackware).
P.S. Да и утилита BleachBit тоже годная вещь.

Я слинковал /tmp в оперативку и у меня тоже чистится автоматически при каждой перезагрузке

Добрый день Леди и джентельмены! Также думаю перейти с дебиан на Слаку но имею пару вопросов.

1. Дебиан смертельно достал тормозами, раньше была и сейчас кой где использую AgiliaLinux ( русский Слакварь как говорили) вот там все было шустро . А как в плане быстрота и отзывчивость в 14.2 ?
2. Версия 14.2 вышла в 2016г стоит ли сразу обновлять? Или обновить только браузеры мультимедиа и тд? Как сие сделать малой кровью ?
3. Как правильно искать и ставить пакеты? Читаю вики кам пишется о нескольких утилитах, а какие лучше?
4. Могут ли менеджеры пакетов слаки работать через прокси ? В Агилии пакет менеджер использовал wget и все было ОК а здесь как?

1. Без описания железа сложно что-то сказать. С другой стороны, всегда можно отрезать раздел и попробовать. Очевидно, что варианты с KDE, XFCE или каким-то WM очень сильно отличаются по прожорливости. Не понравится — удалить и сделать вид, что так и было ;)
2. Речь ведь про обновления безопасности, других для стабильных версий Slackware не выходит. Поэтому обновлять установленное из основного дерева дистрибутива стоит однозначно. Сторонний софт — по собственному усмотрению.
В 14.2 пришла пакость от разработчиков ядра, которые в LTS ветке 4.4.168+ несмотря на статус LTS поменяли интерфейс системных вызовов, как результат была сломана сборка ядерных модулей для некоторого софта, например, VirtualBox, драйверы nVidia и т.п. И если некоторые внесли соответствующие правки в новых версиях, то софт уже неподдерживаемый обновлениями остался в зоне риска. К счастью, самостоятельная замена ядра на ветку 4.9.х эту проблему вполне решает.
3. Я пользуюсь slackpkg, slackpkg+, sbopkg, руками. Мне хватает. Но это не значит, что другие чем-то хуже.
4. Обычно, по крайней мере указанные выше, используют wget, поэтому проблемы, на первый взгляд, не вижу.

Говорят, что привычка — вторая натура, поэтому если без поддержки зависимостей со стороны ПМ никак не прожить, можно попробовать Salix.

_________________
irc://freenode.net/##slackware-ru

Благодарю за ответы! Систему 14 поставил, нравится. Правда аж смешно и позитивно что установщик почти такой как в Mops 7 ( хехе) init как в Mops 6.2 ))) Ну да это все мелочи. Вообще все шустро и все нравится. Вот сквош на overlay-fs туда еше вкорячить ваше взлетим. И будет как Агилия))) С дебиан не сравнить, хорошо

А что с дебианом не так?

Зачем?

Тормоза((( Вот стоит у меня Debian 9 fluxbox - это ужас, старт самого flux по пол минуты, ну как они этого добились? Некоторые проги там - старт по 10-20 сек - ви таки уверены шо эта линукс?
Вот на Агилии у меня flux на худшем железе грузился мгновенно почти. 5-7 сек и можно работать - при этом обновременно грузилась куча асек и тому подобного офисного хлама.
Слакварь установил на тот-же комп где Дебиан ( кусок раздела отрезал с самого конца диска) ничего ,вполне хорошо. Быстро пашет. Напильником малость обработать - заблестит.

1. Прибавка скорости , замеры обсуждения - на старых форумах Агилии да где эти форумы.
2. Больше свободного места в корне. Существенно больше.
3. Возможность быстрого бэкапа и переноса рабочей системы куда и как душа пожелает
Для меня плюсов хватает

Ps Ну правда в Агилии делали свош с ауфс , но с 3 ветки ядра стало возможным использовать оверлейфс которая поставляется вместе с ядром ( ауфс патчи надо накладывать на сорци ядра ) . А с 4 ветки оверлайфс еше и работать стало нормально. Так что вот))))