Как там слака поживает?

Но этот ад зависимостей можно отрегулировать конфигурацией собираемых пакетов, в самом SlackBuild это строка начинающаяся с < ./configure \ " >

Не могу утверждать ничего о MuseScore, но стратегия SBo — не тянуть в обязательное опциональные зависимости. Квинтэссенцией подхода можно назвать слакбилд для ffmpeg:
https://slackbuilds.org/repository/14.2/multimedia/ffmpeg/
для управления сборкой (на самом деле — configure) есть 55 переменных окружения, а jack-audio-connection-kit и
SDL2 подхватываются по факту наличия в системе на момент сборки.

Правда тут очередь на сборку придется написать руками, sqg такого не сумеет.

Поэтому сильно повезет, если окажется достаточно готового, что собирает AlienBOB (Eric Hameleers).

а также некоторых убогих прикладных приложений из XAP.

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

Наоборот, в Слаке мусора мало. Дистрибутив у Патрика очень цельный.

А что за инит?

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

saahriktu>> http://slackbuilds.org/repository/14.2/system/p7zip/
vydrochka> Ващет это и есть из исходников, но вроде тогда его не нашёл.

Бывает. Напомнило:

Ночь, мужик под фонарём вокруг столба на карачках ползает.
— Ты что тут делаешь?
— Ключи ищу.
— Давай помогу. Что-то не видать, точно тут обронил?
— Не, вон там, у забора, но там темень хоть глаз коли.

У «забора»
а) (рецепт сборки):
https://slackbuilds.org/repository/14.2/system/p7zip/
б) а также собранное:
https://slackonly.com/pub/packages/14.2-x86_64/system/p7zip/
https://slackonly.com/pub/packages/14.2-x86/system/p7zip/
в) а если на http://slackfinder.org сходить, там еще по 6 мест для каждой архитектуры есть.

г) а также (slackpkg/slackpkg+):

# slackpkg install p7zip

Looking for p7zip in package list. Please wait... DONE

[ Repository               ] [ Package                                  ]
  alienbob                     p7zip-16.02-x86_64-1alien.tgz             

Total package(s): 1

Do you wish to install selected packages (Y/n)? 

qt5 тут далеко не подарок

Могут ли в Слаке одновременно соседствовать qt4 и qt5. При инсталяции qt5, не сотрёт ли он аналогичные файлы принадлежащие уже пакету qt4? Если пихать в систему qt5 не лучше ли его инсталлировать в каталог /usr/local/ ?

Пятыми кедами AlienBob -а не пользовался? Советует ли AlienBob перед установкой KDE5 удаления qt4?

kde4 точно удалять нужно

Квинтэссенцией подхода можно назвать слакбилд для ffmpeg

Тру-красноглазие. Пока не станешь докой по кодекам, ffmpeg не видать. Причем, сегодня нужны одни кодеки, завтра другие - и снова бубен в руки и канпелять. Это уже какая-та недогента получается. У изкоробочной слаки принципиально иной подход же.

Могут ли в Слаке одновременно соседствовать qt4 и qt5

Вопрос не слакоспецифичен, ответ зависит от того, как сконфигурированы qt4 и qt5.
qt5 на SBo и qt5 у Эрика уже настроены на мирное сосуществование с дистрибутивным qt4, конфликта нет.

Пятыми кедами AlienBob -а не пользовался?

Вполне пригодный вариант.

Советует ли AlienBob перед установкой KDE5 удаления qt4?

Нет. Потеряется работоспособность любого софта, собранного с qt4.
Инструкцию по установке можно почитать там:
http://slackware.uk/people/alien-kde/14.2/5/README

Квинтэссенцией подхода можно назвать слакбилд для ffmpeg

Тру-красноглазие. Пока не станешь докой по кодекам, ffmpeg не видать. Причем, сегодня нужны одни кодеки, завтра другие - и снова бубен в руки и канпелять. Это уже какая-та недогента получается. У изкоробочной слаки принципиально иной подход же.

Если и когда вам этого захочется, у вас уже есть готовое решение.

А если пока не захотелось, там было написано:

Поэтому сильно повезет, если окажется достаточно готового, что собирает AlienBOB (Eric Hameleers).

Это означает буквально следующее:

# slackpkg install ffmpeg

# slackpkg update; slackpkg upgrade-all

Ах да, ffmpeg лучше брать из restricted, который за пределами юрисдикции стран, признающих возможность патентной защиты ПО. Но это если только вы сами вне территории таких стран.

Могут ли в Слаке одновременно соседствовать qt4 и qt5. При инсталяции qt5, не сотрёт ли он аналогичные файлы принадлежащие уже пакету qt4? Если пихать в систему qt5 не лучше ли его инсталлировать в каталог /usr/local/ ?

Пятыми кедами AlienBob -а не пользовался? Советует ли AlienBob перед установкой KDE5 удаления qt4?

у AlienBob они стоят вместе и неплохо таки работают. Как и что слишком долго описывать. Если кратко - qt4 стоит в qt4, qt5 стоит в qt5. Те программы что не осилили qt5 пользуют qt4, те что осилили пользуют qt5. Ещё раз - всё работает без лагов и задурей, плавно и стабильно. Для подробностей читай у самого AlienBob'а в его блоге. https://alien.slackbook.org/blog/

Норм, даже пакетный менеджер накатить можно.

Чтоа? Т.е. по умолчанию его там нет?

Говорят, что кур доят.

Вдова одна, профессорша, три двойни родила,
И двадцать восемь месяцев беременна была;
Когда же разрешилася, собрался факультет,
Велел литографировать родильницы портрет!
Портрет же вы, трещоточки, имеете?.. навряд!
 — «Портрета не достали мы, а только говорят!»

Продолжить список сплетен, слухов и мифов предлагаю самостоятельно и не здесь. Можете С.В.Лаврову рассказать, говорят, он умеет адекватно оценить подобное парой слов, одно из которых «артикль» ^).

Еще хочется узнать, как поступают в случае, когда нужна какая-то проприетарь, а она есть только в deb/rpm? Руками распаковывают?

Еще хочется узнать, как поступают в случае, когда нужна какая-то проприетарь

пример в студию.

Не помню с ходу. Какой-нибудь скайп, но там вроде есть тгз. В таком духе.

Перепаковывают в пакет Slackware, ставят полученный пакет.
Причем, так делают не обязательно с проприетарью — на SBo есть ряд слакбилдов, которые перепаковывают в том числе и бинарные релизы некоторых свободных проектов, сборка которых довольно ресурсоемка.

Для конвертации между форматами пакетов есть в природе софтинка alien. Другой самый простой вариант — распаковать во временный каталог (rpm и ar есть в наличии), поменять что нужно, позвать в нем makepkg.

Например, slack:
http://slackbuilds.org/repository/14.2/network/slack/

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

Еще хочется узнать, как поступают в случае, когда нужна какая-то проприетарь, а она есть только в deb/rpm? Руками распаковывают?

Цитата из Слакбука

Менеджер пакетов Red Hat (Red Hat Package Manager, RPM) - это популярная на сегодняшний день система работы с пакетами. Многие распространители программного обеспечения предлагают свои продукты в формате RPM. Поскольку он не является нашим “родным” форматом, мы не рекомендуем вам использовать его. Однако некотрые вещи бывают доступны только в виде RPM (даже исходные тексты).

Мы предлагаем программу для преобразования RPM-пакетов в наш родной формат .tgz. Это позволит вам развернуть пакет (возможно, с помощью explodepkg) во временный каталог и изучить его содержимое.

Программа rpm2tgz создаст пакет Slackware с расширением .tgz, а rpm2targz создаёт архив с расширением .tar.gz.

позволяет сделать с системой что угодно

А что на самом деле скрывается за этими красивыми словами?
Учитывая сферу применения Slackware на сегодняшний день, можно какие-нибудь примеры?

Только что-то собирается начать не нравиться, смотришь, ан нет, не Slackware, апстрим

Так разве это не проблема? Вот в более иных дистрибутивах майнтейнеры часто вносят полезные правки в пакеты.

выборочно обновить отдельные пакеты до версий из current'а никто не запрещает.

От такого же даже apt поломаться может с зависимостями, там это как решают?

Так в Слаке же нет зависимостей.

Речь о пакетном менеджере. Штатный пакетный менеджер Slackware (pkgtools, slackpkg) не отслеживает зависимостей, его подобные действия не могут поломать — в данном случае нечему ломаться.

Так ведь пакетный менеджер не является самоцелью. Дистрибутив используют для того, чтобы легко получить нужный для работы прикладной софт.
Slackware, всю эту махину, крайне утомительно поддерживать. Особенно если речь идёт о current. А не ставить current не получиться, так как в стабильных релизах (редко выходящих) сильно устаревший софт и не факт что всё железо подхватит. Делать выборочную установку current ещё сложней, чем в случае с стабильным релизом. Приходится делать полную установку, а это уже более 11 Гб. Каждый раз при обновлениях придётся внимательно анализировать изменения конфигурационных файлов. Сборка пакетов по рецептам из slackbuilds.org на current сложней, чем на стабильном релизе.
Слишком много мороки.

Я не на последней версии, а на 14.1, которая используется на рабочем ноутбуке и на походном ноутбуке. Главное преимущество Слаки в том, что комп не считает себя умнее пользователя. Ничего не разваливается само и не живёт своей жизнью. В релиз не тащат всякую глюкоту. Версии ПО на момент установки были достаточно свежие. Есть всё, чтобы и поработать, и отдохнуть от работы.

На этот случай есть rpm2tgz и deb2tgz

можно какие-нибудь примеры

Например, прикладная некромантия. На прошлой работе в университете у меня была лаборатория из компов на Слаке и на соседней кафедре такая же. Слака была выбрана т.к. использовалось древнее железо (P-III с 256М RAM).

табильных релизах (редко выходящих) сильно устаревший софт и не факт что всё железо подхватит

Про железо согласен. А что такого бывает в софте, что требуется именно распоследняя версия? Без current вполне можно жить.

Нет, qt4 и qt5 могут быть установлены одновременно и не мешать друг другу. Это относится как к версии от Эрика, так и к версии со slackbuilds.org

current — это не ролинг, это разрабатывамая версия. Использовать ее как боевую можно только если есть осознанное желание быть бета-тестером и компетенции самостоятельно диагностировать и устранять возникающие проблемы.
Между выходами стабильных (номерных) версий проходит время, это так. Обычно последней версии хватает для сборки и работы актуального софта, а с подъемом версии базовых библиотек приходит время для нового стабильного выпуска.
Использование current не имеет практически ничего общего с использованием стабильной версии Slackware ни по трудоемкости, ни по регламентным процедурам, ни по последствиям обновлений. Распространять опыт использования current на стабильную версию — огромная непростительная ошибка.

Cherry-pick отдельных пакетов из current в stable — это не сравнимо с использованием current, это обычно значительно проще.

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

Полную установку рекомендуют новичкам. Тому, кто не имеет компетенции обслуживать частичную установку stable — о каком current может идти речь?

SBo не имеет версии для current. Но git репо от ponce поедназначен именно для current, ссылку на него можно выбрать в sbopkg. Проблема высосона из ..., элементарная неосведомленность тому причиной.

Кроме сборки при помощи Слакбилдов, можно ещё брать готовые пакеты со slackonly.com, который подключается через slackpkg+.

И рыскаешь потом по багтрекерам деба или федоры, тянешь патчи и ручками накатываешь.

Это страшные сказки. Я ничего не разыскиваю и никакие патчи не накладываю. Можно примеры пакетов озвучить?

Для скайпа был специальный Слакбилд, который автоматически всё перепаковывал.

Сборка пакетов по рецептам из slackbuilds.org на current сложней, чем на стабильном релизе

Повторюсь, использование чего угодно не по своему назначению, значительно сложнее, чем по назначению. Не надо закручивать гвозди отверткой, только и всего.
Использование слакбилда для своей версии одинаково и на stable, и на current:

bash *Build

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

Почитай ChangeLoge стабильной и разрабатываемых версий и сравни с «более иными дистрибутивами» на сколько часто вносятся изменения сторонними людьми. Обычно такие строки начинаются со слов «Thanks to имя_или_никнейм_человека ...». Эти люди просто напросто пишут письмо Патрику где излагают свои мысли и конкретные «рецепты».

Пакеты собирает и помещает в хранилище Патрик самолично.

И ещё, сравнивая, тупо не считай колличество людей, сравнивай их общие пропорции. Так будет честнее.

Это понятно, это я всё предварительно собираю. В итоге я нашёл версию МузеСкоре, которая не падает. У меня есть сильное подозрение, что у Патрика что-то не то с libc: или он не патчит, а все патчат, или у него какая-то версия, как не у всех. Сейчас лень перезагружаться в Слаку и собирать актуальную версию МьюзСкор, но вроде бы она жаловалась на либц тогда.

Возможно, кому-то нравится xterm и xpdf. Лично я нахожу их корявыми и малофункциональными по сравнению с gnome-terminal/evince. Это просто мои личные предпочтения, ничего более. В любом случае, я лишь имел в виду, что от этих приложений ничего критичного в данном случае зависеть не может.

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

Слака насквозь ванильна, если патчи реально необходимы системе Патрик вместе с ними и будет собирает пакеты. А мыслей типа: «раз все накладывают, то и я буду накладывать» у Патрика никогда не возникнет.

Все что ты собираешь из SlackBuild.org должно работать иначе слакбилды туда просто не выкладывались бы. Просто выбираешь на сайте номер своей версии Slackware, пишешь в строке поиска название пакета и вперёд...

И да, файлов в названии, которых наличествует слово *libc* в системе много.

или он не патчит, а все патчат, или у него какая-то версия, как не у всех

Можно подумать, информация закрыта ^)
Актуальный в 14.2 glibc:
slackware-14.2/patches/source/glibc/
собирается так:
slackware-14.2/patches/source/glibc/glibc.SlackBuild
соответственно, поверх ванильной glibc-2.23 применены:

apply_patches() {
  # Use old-style locale directories rather than a single (and strangely
  # formatted) /usr/lib/locale/locale-archive file:
  zcat $CWD/glibc.locale.no-archive.diff.gz | patch -p1 --verbose || exit 1
  # The is_IS locale is causing a strange error about the "echn" command
  # not existing.  This patch reverts is_IS to the version shipped in
  # glibc-2.5:
  zcat $CWD/is_IS.diff.gz | patch -p1 --verbose || exit 1
  # Support ru_RU.CP1251 locale:
  zcat $CWD/glibc.ru_RU.CP1251.diff.gz | patch -p1 --verbose || exit 1
  # Fix resolver problem with glibc-2.9:
  zcat $CWD/glibc-2.10-dns-no-gethostbyname4.diff.gz | patch -p0 --verbose || exit 1
  # This reverts a patch that was made to glibc to fix "namespace leakage",
  # which seems to cause some build failures (e.g. with conntrack):
  zcat $CWD/glibc.revert.to.fix.build.breakages.diff.gz | patch -p1 -l --verbose || exit 1
  # Make it harder for people to trick ldd into running code:
  zcat $CWD/glibc.ldd.trace.through.dynamic.linker.diff.gz | patch -p1 --verbose || exit 1
  # Add a C.UTF-8 locale:
  zcat $CWD/glibc-c-utf8-locale.patch.gz | patch -p1 --verbose || exit 1
  # Upstream git patches for security hardening (CVE-2017-1000366):
  zcat $CWD/glibc.3776f38f.diff.gz | patch -p1 --verbose || exit 1
  zcat $CWD/glibc.46703a39.diff.gz | patch -p1 --verbose || exit 1
  zcat $CWD/glibc.CVE-2017-1000366.3c7cd212.diff.gz | patch -p1 --verbose || exit 1
  zcat $CWD/glibc.adc7e06f.diff.gz | patch -p1 --verbose || exit 1
  zcat $CWD/glibc.c69d4a0f.diff.gz | patch -p1 --verbose || exit 1
  # Don't assert on older Intel CPUs.
  # This fixes an ldconfig failure on Pentium MMX.
  zcat $CWD/glibc.6a824767.dont.assert.on.older.intel.cpus.diff.gz | patch -p1 --verbose || exit 1
}

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

Не юли.

Если внимательно посмотреть, на что именно дан ответ <…>

Ты тоже не юли, особенно с учетом того, на что был дан ответ.

Речь о пакетном менеджере. Штатный пакетный менеджер Slackware (pkgtools, slackpkg) не отслеживает зависимостей, его подобные действия не могут поломать — в данном случае нечему ломаться.

Его ­— может быть и не могут, а вот ПО, им устанавливаемое — запросто.

Нет, это Вы что-то додумываете. В скольки случаях из скольки фраза «я опять поломал зависимости» относится именно к тому, что бинарники не находят нужные им *.so файлы? Да в 10-ти случаях из 10-ти речь именно про то, что пакетный менеджер запутался в зависимостях - одному пакету нужны одни зависимости, а по зависимостям другого пакета они должны быть удалены. И т.д. и т.п. В Слаке такого нет.

Его — может быть и не могут, а вот ПО, им устанавливаемое — запросто.

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

Максимум, что может быть - ряд бинарников не найдут нужные им *.so файлы.

Вот для того, чтобы такой катастрофы не случилось, и нужен полноценный пакетный менеджер.

Это не катастрофа.

Максимум, что может быть - ряд бинарников не найдут нужные им *.so файлы.

Подумаешь, ерунда какая.

Вот для того, чтобы такой катастрофы не случилось, и нужен полноценный пакетный менеджер

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

Повторюсь, ситуация, когда на диске есть бинарники, которым не хватает библиотек, для неполной установки Slackware вполне обычное дело, см.: Как там слака поживает? (комментарий)

не юли, особенно с учетом того, на что был дан ответ

Не тупи.
ПМ выполняет то, что ему сказали. Сказали поломать — поломает, сказали починить — починит. В Slackware так, иного от ПМ никто не ждет (и не должен), потому как иного обещано не было.
Если ждали чего-то большего — ошибка не в ПМ.

ПМ выполняет то, что ему сказали.

Было бы странно, если бы он этого не делал. И это никоим образом не отменяет тот факт, что фраза «в Слаке нет зависимостей» — вызывающе неверное 4.2.

фраза «в Слаке нет зависимостей» — вызывающе неверное 4.2.

В Slackware нет пакетных зависимостей: операция установки/удаления пакета обычно не зависима от наличия/отсутствия другого пакета.
В Slackware есть зависимости бинарник/библиотека, сценарий/утилита и т.п., их не может не быть, ибо это вне сферы дистрибутива (ситуацию всё слинковано статически не рассматриваем :-) ), так уж они (бинарники/сценарии) везде устроены.
В Slackware обычно осознанное нарушение администратором зависимости бинарник/библиотека, сценарий/утилита и т.п. с точки зрения дистрибутива до определенных пределов безразлично (это на случай, если в аргументах появится libc).

Что мешало сразу так и сказать?

Что мешало сразу так и сказать?

Наверное то, что «сразу» говорил кто-то другой ^)

А в целом, обычно акцентируют внимание на отличиях одного от другого. Действительно, какой смысл акцентировать внимание на том, что везде одинаково? Про Slackware Linux сказано, что это система на ядре Linux с обвязкой из GNU и прочих утилит, по составу более-менее соответствует «основной струе», собирается системным gcc, и т.д. и т.п. Это уже само по себе говорит, что в этой части оно в среднем по больнице «как везде». А дальше начинаются акценты: чем отличается. И если для книги и статьи отсутствие подробного вступления — существенный изъян, то для форумного сообщения не повторять каждый раз общеизвестные факты, полагаю, вполне естественно, тем более что сам формат общения позволяет уточнить как контекст, так и сделанные смысловые акценты.

Интересно узнать, Slackware всё ещё KISS или уже нет?