Традиционная Slackware

aptitude на практике всегда норовил вынести половину системы и доставить кучу мусора. apt-get с зависимостями обходится гораздо корректнее. А «apt-get -f install» быстро пофиксит зависимости. Возможно, с удалением пакетов для которых нет зависимостей, но это уже другой вопрос. Можно даже сначала доустановить отсутствующие зависимости руками через «dpkg -i», а уже потом вызвать «apt-get -f install».

Вообще Slackware в этом плане от Debian отличается только одним — количеством пакетов. Если бы Debian тоже имел основной репозиторий на 2,7 ГБ и для него кто-то на общественных началах организовал debbuilds.org, то Debian тоже называли бы source-based.

Не думаю, что главное преимущество шлаку в компактности и отсутствии зависимостей. Перефразирую слова Патрика «Если вы знаете Slackware — вы знаете GNU/Linux. Если вы знаете Debian, то всё, что вы знаете, — это Debian». Всё-таки во многих дистрибутивах столько дополнительных скриптов-костылей, которые только загоняют пользователя в непонятные рамки и не дают «почувствовать систему» на кончике пальцев.

выкачивать зависимости того же дебиана было бы адом

В слаке есть какой-то магический способ установить пакет без установки пакетов, от которых он зависит?

я, наверное, недостаточно мелко написал слово ВРУЧНУЮ

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

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

вот, например, я выбираю asciidoc. смотрю на индикатор - полтора гигабайта будет занято после установки. я нервно икаю, нажимаю g, и вижу, что в числе мягких зависимостей dblatex, который тянет texlive, который тянет 1.5 гб хлама. я убираю dblatex, нажимаю q, и снова нажимаю g. ага, пакетов стало значительно меньше, каких-то 10 мб, и dblatex переместился в нижний список *рекомендуемые*. заглядываю в него, вижу там w3m, который нужен для генерации текстовых файлов через обёртку. а вот это мне нужно, отмечаю его, смотрю индикатор - всё ок. я снова жму g и через минуту у меня установлен asciidoc с нужными мне опциями.

ни в какой НЕВИЗУАЛЬНОЙ хрени я не мог бы так натыкать

с версиями, когда смешиваешь репы - аналогично. перемещаешься по битым пакетам и вручную разрешаешь, по пути сверяясь с авторешальщиком. если результат НЕ устраивает, то ты его видишь заранее, не нажимаешь второй раз g, а тыкаешь в меню *отменить все незаконченные действия* и думаешь, как это сделать лучше.

ничем, кроме интерфейса aptitude, я в debian не пользуюсь - потому что всё остальное ненаглядно, во всём остальном я не могу влезть в ЛЮБУЮ стадию и на любой этой стадии что-то отменять

вот возьмём абстракный пример - тебе нужны элементы 1-20, но без 3 и без 17, плюс элемент 72, выделяемые одним запросом, тогда как стандартная зависимость - это элементы 1-20. в запросовом случае ты конструируешь мега-запрос, который учитывает все такие тонкости, а в случае интерактивного режима - даёшь только действия *дай мне элемент 1-20*, а потом с помощью стрелочек/поиска снимаешь отметку с 3, с 17 и ставишь отметку на 72 - быстро и просто

тогда OpenBSD ещё баще. в нём есть бинарный реп с самыми популярными FLAVORS, и есть дерево портов, где можно использовать любые FLAVORS и их комбинации

например вимов в бинарном виде 9 штук.

vim-8.0.0388-gtk2-lua.tgz
vim-8.0.0388-gtk2-perl-python3-ruby.tgz
vim-8.0.0388-gtk2-perl-python-ruby.tgz
vim-8.0.0388-gtk2.tgz
vim-8.0.0388-no_x11-lua.tgz
vim-8.0.0388-no_x11-perl-python3-ruby.tgz
vim-8.0.0388-no_x11-perl-python-ruby.tgz
vim-8.0.0388-no_x11-ruby.tgz
vim-8.0.0388-no_x11.tgz

быстро и просто

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

Вообще-то никто не запрещает выкладывать бинарные пакеты для любых дистрибутивов. Только обычно нет проблем и в собственной сборке пакетов. Особенно если это не тяжёлый софт.

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

Тут целиком бинарные дистрибутивы, конечно, удобнее. Однако, собирать все возможные пакеты со всеми возможными опциями никто не будет. В случае сложных требований всё равно придётся допиливать под них, а это опять компиляция. С другой стороны, в целиком бинарных дистрибутивах может потребоваться компилять меньше. Ну так тут и от набора нужных пакетов многое зависит. Если пакетов не так и много, то можно так или иначе и покомпилять. А вот если пакетов очень много, а самолёт через полчаса...

ничего он не подставляет и ничего не выносит. и это гораздо быстрее - тебе даже не нужно вводить полное название пакета, проще найти его поиском, введя 3-4 буквы. затем заглянуть в солвер, посмотреть первых 2-3 варианта. если не устраивает, выйти из солвера и с помощью клавиши b перемещаться по сломанным пакетом, визуально наблюдая, в чём проблема. если проблема не решается за эти несколько нажатий - то уже надо детально разбираться. и единственный инструмент, который может детально разбираться, вручную разводя все зависимости, пока солвер не будет доволен - это aptitude

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

пример - мне нужно поставить бэкпортнутую версию supertuxkart

/kart - тут мне попадётся supertuxkart-dbg

n - тут мне попадётся уже supertuxkart. в любом случае, n будет циклически перемещать между 4 пакетами - двумя указанными, -data и каким-то gps-приложением с хитрым названием

v (стрелка-вниз) +

смотрим, если не покраснело и зависимости все решены - g g. если нет - см выше, солвер и переход по broken

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

по сравнению с apt - это как сравнивать ed и vim

ничего он не подставляет и ничего не выносит

Вероятно, это ещё зависит от набора установленных пакетов, но по моему опыту он именно подставляет и выносит. Даже тогда, когда «apt-get -f install» говорит, что всё OK, и все зависимости в порядке, aptitude сразу после старта подставляет горы пакетов как для установки, так и для удаления. Мол, нужно для разрешения зависимостей.

Перефразирую слова Патрика «Если вы знаете Slackware — вы знаете GNU/Linux...

Откуда инфа что это он сказал?

Откуда инфа что это он сказал?

В оригинале фраза, приписываемая то ли Патрику, то ли кому-то ещё из адептов шлаки, звучит так: «Если вы выучили Red Hat, то всё, что вы знаете, — это Red Hat, если вы выучили Slackware — вы знаете Linux»

Не думаю, что главное преимущество шлаку в компактности и отсутствии зависимостей. Перефразирую слова Патрика «Если вы знаете Slackware — вы знаете GNU/Linux. Если вы знаете Debian, то всё, что вы знаете, — это Debian»

Только вот сделать ничего не сможите, так как что на красной шапке, что на дебиане, что на арче системд.

Смогут, еще как смогут. Легким движением руки, любой дистрибутив превращается... (барабанная дробь) в slackware.

Не пробивал несколько слоев бревен.

Легким движением руки, любой дистрибутив превращается... (барабанная дробь) в slackware.

Если создать полотно скриптов в роли инита ещё можно воспользовавшись юнитом systemd, то разобраться за зависимостями/юнитами будет для них непосильной задачей.

Не пробивал несколько слоев бревен.

Не пробивал wifi на телефоне или же сеть от оператора?

Сеть то от оператора принимал, на чердаке правда, а вот раздать wifi он не мог, сигнал не пробивал слои бревен, да и грелся телефон как мразь, приходилось еще и на зарядке его держать.

В слаке есть какой-то магический способ установить пакет без установки пакетов, от которых он зависит?

Почему магический? Штатный.
Установить любой пакет — да, без проблем, штатный вызов
installpkg файл-пакета
установит пакет. Рация на бронепоезде. Пакетный менеджер без автоматического разрешения зависимостей.

А какова была скорость на столь !«расслабляющем» отдыхе?

Не более 100 кб/сек. Но я был рад и этому. Деревня, отдых на террасе с ноутбуком, заварил себе чай и сиди жди, зато сразу учишься ценить то что есть.

«apt-get -f install» говорит, что всё OK

ну потому что надо знать, чем они отличаются. надо - поднимай пиннинг

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

-- доктор, я когда вот так вот делаю, у меня жопа болит

-- а вы пробовали так не делать?

Не более 100 кб/сек

Связь часто рвалась?

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

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

Ростелеком - то еще говно.

КЭП заявляет, что Ростелеком имеет огромное покрытие и разнообразную инфрастуктуру. Зачастую бывает, что был какой-то другой провайдер, которого он просто поглотил.

Соответственно, даже в одном Санкт-Петербурге можно найти два дома с Ростелекомом, и в одном будет всё отлично, а в другом ужасно.

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

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

Прямо юношеский максимализм какой-то. Ну-ну...

Давайте по-порядку.

Во-первых, в исходном сообщении утверждение было не про «работать», а про «поставить»:

В слаке есть какой-то магический способ установить пакет без установки пакетов, от которых он зависит?

Об чём был вопрос, об том был и ответ. В Slackware одиночный пакет (или их группу) всегда можно поставить или удалить (но некоторые — не стоит).

Во-вторых, определение определению рознь. Вот то определение, что приведено выше про «зависимость пакета» — кривое как турецкая сабля, ибо работают не пакеты, а программы. Например, посмотрим на пакет nmap в Slackware:

# grep bin/ /var/log/packages/nmap-*
usr/bin/
usr/bin/ncat
usr/bin/ndiff
usr/bin/nmap
usr/bin/nping
usr/bin/uninstall_ndiff
usr/bin/uninstall_zenmap
usr/bin/zenmap