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

Все еще KISS ^)

current — это не ролинг, это разрабатывамая версия. Использовать ее как боевую можно только если есть осознанное желание быть бета-тестером и компетенции самостоятельно диагностировать и устранять возникающие проблемы.

Как в эту концепцию уложить наличие Slackel, прeдназначенного для домашнего пользования ?

Удобство? Это не про слаку

Че это не про слаку? «удобство» — это все субъективно.

Каков алгоритм и порядок установки зависимостей и зависимостей этих зависимостей в слаке ? В дебиане все расскажет-покажет и разрулит синаптик, а в слаке ? Навеяно Зависимости пакетов

Кто ж его знает, как.
Предположу, как Manjaro и Arch, но это не точно ^)

На самом деле, если не использовать самосборного софта, то будут ловиться только ошибки дистрибутива, кои бывают, хоть и относительно редко, и исправляются дистоибутивом по обнаружении (но голова и руки нужны все равно). А вот если есть самосборный софт — готовьтесь к пересборкам его на каждую смену использованных им soname, плюс к тому, что может не пересобраться. Оно такое надо зачем?

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

Я часто привожу пример с nmap, можете поиском его найти. Зачем мне в консольной минисистеме зависимости для входящих в этот пакет файлов: питон и иксы?

Это же слака. Там всё всегда хорошо.

Если вдруг собираешь пакет не содержащийся в репозитории например, из SlackBuilds.org, возьмём MuseScore. Там написано: «This requires: jack2, portaudio, lame, qt5-webkit», то есть перед сборкой MuseScore сначала собираешь и устанавливаешь эти 4 пакета. В свою очередь qt5-webkit требует пакета qt5, так что перед сборкой qt5-webkit сначала собираешь и устанавливашь qt5. А qt5 требует libxkbcommon, libinput. Перед сборкой qt5 предварительно собираешь и устанавливаешь пакеты libxkbcommon и libinput.

Вопрос: как построить это дерево зависимостей, необходимых для сборки, чтобы можно было последовательно собирать и подыматься к основной программе ? Есть что сказать слаководам ?

наоборот, удаление одного из пакетов тянет за собой удаление ряда пакетов. В Слаке такого нет. А потому можно, например, спокойно временно вынести пакет, который нужен половине системы, и все остальные пакеты останутся на своих местах.

Вот в дебиане такое предупредит синаптик. А в слаке юзер, удаляя пакет и его зависмости (ну надоел он ему и он решил его удалить) легко может сломать систему, но узнает он об этом значительно позже, возможно он уже и забудет, что удалял пакет. Нда, иная простота хуже воровства. Есть что сказать слаководам ?

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

Конечно ! Вот пускай знатоки попробуют поставить в 14.2 kdenlive более-менее свежий, а не 0.9.10 что в стейбл. Ау, знатоки ! Осилите ?

Вопрос: как построить это дерево зависимостей, необходимых для сборки, чтобы можно было последовательно собирать и подыматься к основной программе ?

# sqg -p MuseScore
# sbopkg -ki MuseScore.sqf

Вторая строка про то, как это дерево собрать, не пересобирая уже установленное.

возможно он уже и забудет, что удалял пакет

$ ( cd /var/log/removed_packages ; ls -ot )

Список когда и чего удалял в хронологической последовательности.

Вот пускай знатоки попробуют поставить в 14.2 kdenlive более-менее свежий, а не 0.9.10 что в стейбл.

kdenlive-17.08.3 пойдет за свежий?
https://alien.slackbook.org/ktown/14.2/5/x86_64/kde/applications/
https://alien.slackbook.org/ktown/14.2/5/x86/kde/applications/

Ставить KDE5 так: https://alien.slackbook.org/ktown/14.2/5/README

На slacbuilds.org зависимости учитывают, на slacky.eu - тоже.

Список когда и чего удалял в хронологической последовательности.

Та ну это-ж ответ из категории «как разгребти». А вопрос поставлен - «как не вляпаться» то-бишь как не поломать.

Вы часто предлагаете юзерам поставить слаку, но такие предложения вызывают реакцию как в «Бриллиантовой руке»: «Нет уж, лучше вы к нам», потому что внятной документации к слаке как раз и нет ! Че читать то про работу с репами, пакетами, зависимостями ? Примитивный слакбук ? Про три команды работы с пакетами ? Есть тонны обрывочной инфы из постов слакоюзеров, есть readme к слакоинструментам, которые бесполезны для новичков по причине отсутствия базовых знаний. И пока слаководы не займтся этим вопросом вплотную, не напишут (или переведете) практически ориентированные инструкции для новичков, собрав воедино уже написанное и появившееся со времен выхода слакбука, не напишут конкретные «делай так-повторяй за мной» или нормальные руководства как в прочих дистрах, усилия по популяризации слаки бесполезны или имеют низкий КПД.

на slacky.eu - тоже

Личное мнение, не претендующее на истину в последней инстанции:
когда-то довольно давно (еще linuxpackages, если кто такой сайт помнит, был живой или даже еще не родился) пробовал с их репо пожить. В конечном итоге отказался — они традиционно собирали софт с как можно большим (часто, на мой тогдашний взгляд, неоптимальным) количеством возможностей, получая довольно ветвистые зависимости у пакетов. Совмещать их варианты с самосбором или другими источниками также было не шибко удобно.
Как оно там теперь — не скажу, с тех пор не смотрел, но «осадочек» остался :-)

Че читать то про работу с репами, пакетами, зависимостями ?

Читайте вот этот исчерпывающий документ из одного предложения:

В полной установке Slackware все зависимости разрешены, не парьтесь, просто используйте систему по назначению.

Примитивный слакбук ? Про три команды работы с пакетами ?

Да, Этого вполне достаточно.

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

Выделение — моё. Почему именно Slackware должна давать базовые знания по всем линуксам и тому, что рядом? Почему недостаточно знаний только по особенностям самого дистрибутива? Мухи отдельно, котлеты отдельно.
У меня есть небольшой опыт ответов на конкретные и не очень вопросы, переводов и прочая подобной мути. Для ответов часто достаточно слакбука, реже — общих знаний, но обычно достаточно тривиального понимания, как и почему вся эта кухня устроена. Просто утрачена (точнее, не приобретена новым поколением) культура того, что называлось unix-подобная система. И не сказать, что осталась сильно востребована ^)

... усилия по популяризации слаки бесполезны или имеют низкий КПД

Понимаете какое дело... тех, кому интересно разобраться, всегда было мало. Slackware предлагает совсем тривиальную модель — мы тут собрали и притерли друг к дружке некоторое количество софта, поставь все, да и начинай уже пользоваться по назначению. Как сторонние дрова доустановить и графический вход включить информация тоже не секретная. Однако занятие интеллектуальной деятельностью без приложения интеллектуальных усилий, хотя и очень сильно востребовано, пока не очень-то и возможно ^)

Слака никогда не была KISS. Это анти-KISS в чистейшем виде.

Это анти-KISS в чистейшем виде.

Почему, например?

Слака никогда не была KISS

Слака всегда держалось во внутреннем устройстве принципа «не усложняй». Если без чего-то можно обойтись, скорее всего, это не будет принято в дистрибутив.

Заинтригован, с удовольствием послушаю аргументы в пользу утверждения

Это анти-KISS в чистейшем виде

с удовольствием послушаю аргументы

Вангую очередной раунд полемики на тему «сложно жить без пакетного менеджера», «нет вменяемой системы инициализации», «Патрик — бог» и дальше по списку. Я бы с удовольствием послушал мнение, почему однотипные темы про слаку появляются на лоре с завидной регулярностью? Это уже, кажется, третья за последние полгода.

почему однотипные темы про слаку появляются на лоре с завидной регулярностью?

(задумчиво) Может это отвечающие (в том числе и я) скатывают их в унылую утилитарщину вместо кровь-кишки-рас...ило?

PS. А может как в анекдоте про йогурт:
https://www.youtube.com/watch?v=A201QM4IPME

 — Что это у вас там такое красивое?
 — Это йогурт Slackware.
 — А, й-о-г-у-р-тSlacklware... Две бутылки водки, пожалуйста.

Во что они скатываются-то понятно. Создают зачем? Слава Логовского не даёт покоя?

Создают зачем?

Как тема для беседы — ни хуже, ни лучше всяких других тем. Предположим, от нечего делать.

Почему отзывы о Arch Linux такие разные? (комментарий)

Если без чего-то можно обойтись, скорее всего, это не будет принято в дистрибутив

Вот именно, даже если это упрощает систему.

Почему отзывы о Arch Linux такие разные? (комментарий)

Набор абстрактных рассуждений.

То есть, примеров опять не будет... Жаль.

Тут следовало бы сделать акцент в KISS на слове keep, отсутствующем в русском варианте «не усложняй». А вот чтобы, сохранять простым, надо это простое, как минимум знать и понимать. Что случается, к великому сожалению, не слишком часто.

надо это простое, как минимум знать и понимать. Что случается, к великому сожалению, не слишком часто.

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

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

Аргумент. Я как-то упустил это из виду.

Вот именно, даже если это упрощает систему.

Куда ей еще быть проще ? Примитивна и архаична по устройству. Сложна и неудобна в использовании.

Вот тебе и Bormant еще аргумент. Там выше был вопрос про удаление зависимостей из системы. Ответа не было. Потому что нет его. И здесь http://www.slackware.ru/forum/viewtopic.php?f=9&t=348 схожее спрашивали:

Сложности возникают с удалением программ. А именно: на данный момент, при помощи sbopkg, было установлено более двадцати различных программ и зависимых пакетов к ним. К примеру, тот же mkvtoolnix в качестве зависимостей потребовал: ORBit2 GConf wxGTK libebml libmatroska (изначально в системе их не было). Допустим, теперь я хочу удалить mkvtoolnix; в sbopkg, в соответствующем меню, ставлю «звёздочку» напротив mkvtoolnix, даю команду удалить. Mkvtoolnix удалился, но остались его зависимости: ORBit2 GConf wxGTK libebml libmatroska. Естественно, зная, что эти зависимости были установлены сугубо для mkvtoolnix, я могу не боясь удалить их за ненадобностью. Казалось бы, всё просто, да вот беда, программ, а также зависимостей к ним, уже больше двух десятков. Встаёт такой вопрос: как не удалить лишнего, но и не превратить систему в файлопомойку?

Ответ был: «Сам ставил, сам удаляю. На память не надеюсь, записываю.»

Понятно, да ? Записывать.. В прочих дистрах пакетный менеджер предупредит о опасности поломать систему, а тут записывать надо. Ну, да, система проще некуда..

Еще вопрос-контрольный выстрел в слакоголовы: в дебиане если юзер таки удалил важные пакеты из системы, пак.менеджер при установке сам об этом сообщит и предложит легко разрулить ситуацию, сделав apt-get install -f А что предложит юзерам слака ? Ничего. Как можно диагностировать поломку в системе, кроме неожиданно для себя разбив голову ? Никак.

Еще вопрос-контрольный выстрел в слакоголовы:

сомнительный со всех сторон аргумент. Ты поди небось ещё и мэйл.ру-агент юзаешь с амигой ?

Из практики наблюдение - установленная и настроенная один раз в 2012 году система у человека вообще далёкого от каких либо IT спокойно прожила до сего дня без каких либо сбоев. Только флеш-плеер раз в пол-года обновляли.

Если свербит в одном месте - каждый день что-то там ставить-удалять НЕ ИСПОЛЬЗУЙ СЛАКУ, тебя никто не агитирует ей пользоваться.

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

Понимаете какая штука, вопросы ваши праздные, интереса реального за ними нет, написанная в ответ портянка канет в лету. Если скажу вам, что всё решаемо — не поверите. Если дам ссылку на топики, где «apt-get install -f» разносит систему в хлам, скажете, Debian/Ubuntu/Mint не виноваты, это всё сглаз, порча и прочая нечисть.
Поэтому вариант ответа «Сам ставлю, сам удаляю. На память не надеюсь, записываю.» в этой ситуации — оптимальный, и, что самое главное, соответствует истине.
Голова на плечах, руки из плеч, разбить первое и сломать второе удалением важных пакетов из системы невозможно. А головой и руками отчего б и не починить? Крайний случай — используем установочный носитель, монтируем корень, отдельные ФС, используем ПМ для установки/переустановки «неожиданно удалённого», ПМ тот же самый, команды те же самые (installpkg, removepkg)...

Есть ряд состояний, где в Debian/Ubuntu/Mint уже «все пропало», а с точки зрения Slackware еще ничего нештатного не произошло. Более того, бывают такие состояния, когда «ремонт» противопоказан. И, конечно, куда без них, пара штатных вопросов про накатить из бэкапа или с локального репо.

сомнительный со всех сторон аргумент. Ты поди небось ещё и мэйл.ру-агент юзаешь с амигой ?

Меткий выстрел с моей стороны, а ? В десяточку. Сами ж хотели аргументов. Ну нате вам.

Из практики наблюдение - установленная и настроенная один раз в 2012 году система у человека вообще далёкого от каких либо IT спокойно прожила до сего дня без каких либо сбоев. Только флеш-плеер раз в пол-года обновляли.

Это про любу систему сказать можно, если там только флеш-плеер обновлять.

Если свербит в одном месте - каждый день что-то там ставить-удалять НЕ ИСПОЛЬЗУЙ СЛАКУ, тебя никто не агитирует ей пользоваться.

Так я ж про то и говорю: слака на десктопе - это для маргиналов, фриков и тех, кому кроме фурифокса ничего не нужно.

Встаёт такой вопрос: как не удалить лишнего, но и не превратить систему в файлопомойку?

Я для этого наговнокодил лисапед, который разгребает REQUIRED от sbopkg. На дистр, где это есть «из коробки» просто западло переходить (читай: упоротый адепт). А файловая помойка в слаке известно, откуда начинается. И с установкой пакетов она мало коррелирует.

Меткий выстрел с моей стороны
Так я ж про то и говорю: слака на десктопе - это для маргиналов, фриков и тех, кому кроме фурифокса ничего не нужно.

fix

«я не влюблён в себя, а только нравлюсь»

очень походит на размышлизмы школьника с айфоном.

Про записываю — пакетный менеджер за вами много чего записывает, спросите у него ;)

Про конкретный вопрос:

остались его зависимости: ORBit2 GConf wxGTK libebml libmatroska

Нет записей, память подводит, логика не работает, так возьмите какой-нибудь инструмент, вроде:

# sbbdep --whoneeds /var/log/packages/ORBit2-[0-9]*
# sbbdep --whoneeds /var/log/packages/GConf-[0-9]*
...

Так я ж про то и говорю: GNU/Linux на десктопе - это для маргиналов, фриков и тех, кому кроме фурифокса ничего не нужно.

Пофиксил, не благодари.

Я для этого наговнокодил лисапед, который разгребает REQUIRED от sbopkg

Для этого может оказаться лучше sbbdep, hoorex и еще кучка подобных «отвечателей на главный вопрос в Slackware». Не подумайте, что это в сторону велосипеда критика, просто предложение посмотреть вокруг.

Еще вопрос-контрольный выстрел в слакоголовы: в дебиане если юзер таки удалил важные пакеты из системы, пак.менеджер при установке сам об этом сообщит и предложит легко разрулить ситуацию, сделав apt-get install -f

Давайте посмотрим на простом примере. Пример мне вам дать или сами приведете?

Давайте начнем с самого простого. Например, пусть в Slackware это будет:

# removepkg kernel-huge
# reboot

Не подумайте, что это в сторону велосипеда критика

Ни в коем случае.

просто предложение посмотреть вокруг

Да понятно, что это всё уже решено и не по разу. Я просто пыхтон пытался осилить и нашёл для него такую прикладную задачу. Баловство, не больше.

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

На самом деле ядро не является Important-пакетом, так что вводить «Yes, do as I say» не придётся. Но в случае именно с загруженным сейчас ядром вылезет сообщение по поводу разумности данного действия с возможностью отменить удаление.

Даже когда выпиливаешь последнее оставшееся ядро?

Нормально.

Пример 2. Linux Mint

$ sudo -i
# ( cd /boot ; ls vmlinuz-* )
vmlinuz-4.4.0-112-generic
# rm /boot/vmlinuz-*

# apt install -f  # очевидно бесполезен
# reboot

Но в случае именно с загруженным сейчас ядром вылезет сообщение по поводу разумности данного действия с возможностью отменить удаление.

Уверены?

# uname -a Linux mint 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# ( cd /boot ; ls vmlinuz-* )
vmlinuz-4.4.0-112-generic

# apt remove linux-image-4.4.0-112-generic
Пакеты, которые будут УДАЛЕНЫ:
  linux-image-4.4.0-112-generic linux-image-extra-4.4.0-112-generic
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 2 пакетов, и 0 пакетов не обновлено.
После данной операции, объём занятого дискового пространства уменьшится на 220 MB.
Хотите продолжить? [Д/н] 
...
The link /vmlinuz is a damaged link
Removing symbolic link vmlinuz 
 you may need to re-run your boot loader[grub]
The link /initrd.img is a damaged link
Removing symbolic link initrd.img 
 you may need to re-run your boot loader[grub]

# apt install -f
...
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.

Это был эквивалент примера 1 от Slackware. Рассказывайте, как там у вас теперь это починить после неудачного ребута. Полагаю, и в примере 1, и в примере 2 действия будут одинаковые. Желательно в блоке [ code ], а не общими рассуждениями в пользу бедных.

Бред какой-то. Такая ситуация и возникнуть не может ибо в синаптике vmlinuz юзеру никак не встретится. Еще раз: любая операция по удалению пакета от которого зависят другие пакеты вызывает появление в синаптике окна, которое скажет, что данное действие затрагивает другие пакеты, и приведет список этих пакетов. А в слаке такого нет и не будет. Вот и все. И да, -f чинит. А в слаке такого нет и не будет.

А в слаке такого нет и не будет.

И не надо. Мало ли что там пакетный менеджер нарешает. Надёжнее самому руками всё починить.

А в слаке такого нет и не будет.

Конечно не будет. Слака и после пример 1, и после пример 2
перезагрузится обычным образом.
Починка (не раздумывая):

# slackpkg install kernel-huge    # если был удален пакет
# slackpkg reinstall kernel-huge  # если был удален файл
# lilo